Strukturering av ostrukturerade data

(1)

Adam Rydberg

Strukturering av ostrukturerade data

En studie av MSBs kundtjänst

Structuring unstructured data

A study of MSB’s customer service

Informatik Kandidatuppsats

Termin: VT - 18

Handledare: John Sören Pettersson

(2)

Abstrakt

Syftet med uppsatsen är att jämföra olika tillvägagångsätt för att strukturera ostrukturerade data, samt förklara valet av tillvägagångssätt för att strukturera Myndigheten för Samhällsskydd och Beredskaps data gällande IT-ärenden på deras kundtjänstavdelning. En enkätstudie och ett användartest har genomförts på MSB för att undersöka hur struktureringen av deras data kan förbättras. Resultatet från studierna har använts som grund för att skapa en taggningsmall och två olika dokumentmallar, vars uppgift är att sätta regler på hur data ska struktureras. Efter utförd studie rekommenderas MSB använda den framtagna taggningsmetoden Rydbergs taggningsmetod, samt de två dokumentmallar som framtagits och modifierats efter ett användartest. MSB rekommenderas även att ha regelbundna avdelningsmöten där de granskar veckans nyskrivna dokument, samt att följa ett antal riktlinjer som överlämnats vid avslutat exjobb.

(3)

Innehåll

Abstrakt ... 2

1. Inledning ... 1

1.1 Studie på MSB ... 1

1.2 Problembakgrund ... 1

1.3. Syfte ... 2

1.3.1 Uppdrag från MSB ... 2

1.3.2 Syfte för kandidatuppsatsen ... 2

1.3.3 Undersökningsfrågor ... 2

1.4 Målgrupp ... 3

1.5 Avgränsningar ... 3

1.6 Etiska överväganden ... 3

1.7 Begrepp ... 4

2. Teori kring strukturering av data ... 5

2.1 Litteraturstudie ... 5

2.2 Tillvägagångssätt för att strukturera data ... 6

2.2.1 Taggning ... 6

2.2.1.1 Kollaborativ taggning vs individuell taggning ... 6

2.2.1.2 Strukturerad vs ostrukturerad taggning ... 7

2.2.1.3 Kombinationer av tillvägagångssätt ... 7

2.2.1.3.1 Individuell ostrukturerad taggning ... 8

2.2.1.3.2 Individuell strukturerad taggning ... 8

2.2.1.3.3 Kollaborativ ostrukturerad taggning ... 8

2.2.1.3.4 Kollaborativ strukturerad taggning ... 9

2.2.1.4 Homonymer och synonymer ... 9

2.2.2 Trädstruktur ... 10

2.2.2.1 För- och nackdelar med trädstruktur ... 10

2.2.2.2 Föränderliga träd vs oföränderliga träd ... 11

2.3 Strukturering inom dokument ... 11

2.3.1 Förhållandesätt vid skapande av dokument... 11

2.4 Precisering av forskningsfrågor ... 13

3. Tillvägagångssätt och metodval ... 14

3.1 Vetenskapligt angreppssätt ... 14

3.2 Praktiskt angreppssätt ... 14

3.2.1 Granskning av gamla dokument ... 14

3.2.2 Val av tillvägagångssätt för datastruktur ... 15

3.2.2.1 Taggning vs trädstruktur ... 15

(4)

3.2.2.2 Metodval inom taggning ... 16

3.2.2.3 Synonymhantering vid användning av Rydbergs taggningsmetod ... 17

3.2.3 Val av system ... 18

3.2.3.1 Konfiguration av Jira Service Desk och Confluence ... 18

3.2.4 Framtagning av Dokumentmallar och taggningsmall ... 18

3.2.4.1 Mallutformning ... 18

3.2.4.1.1 Artikelmall - Instruktion ... 19

3.2.4.1.2 Artikelmall - Felsökning ... 20

3.2.4.1.3 Regler och riktlinjer vid skapande av ett dokument ... 21

3.2.4.1.4 Rutin för dokumentation ... 21

3.2.4.2 Taggningsmall ... 22

3.3 Insamling av data ... 22

3.3.1 Enkätstudie ... 22

3.3.2 Pilotstudie av enkät ... 23

3.3.2.1 Resultat av pilotstudien ... 23

3.3.2.2 Ändringar efter pilotstudien ... 23

3.3.3 Användartest - Artikelmallar och taggningsmall ... 23

4. Resultat av enkätstudie, användartest och dokumentgranskning ... 25

4.1 Enkätstudie ... 25

4.1.2 Sammanställning av generella och specifika taggar ... 25

4.1.3 Sammanställning av del 2 i enkäten ... 26

4.2 Användartestresultat ... 27

4.2.1 Testperson 1 ... 27

4.3 Granskningsstatistik ... 31

5. Analys av exjobbsresultat och empiriska studier ... 32

5.1 Granskningsstatistik ... 32

5.2 Strukturförhållanden mellan dokument ... 32

5.2.1 Analys av Rydbergs taggningsmetod för strukturering av data ... 33

5.2.2 Synonymhantering för taggar ... 34

5.3 Struktur inom dokument ... 34

5.3.1 Analys av dokumentmallar ... 34

6. Slutdiskussion ... 37

(5)

6.1 Slutsatser ... 37

6.1.1 Förändringar i dokumentmallarna ... 37

6.1.2 Rekommendationer ... 37

6.1.3 Kunskapsbidrag ... 38

6.2 Pitch av pilot och potentiellt fortsättningsarbete ... 39

7. Omnämnande ... 40

Referenser ... 41

Skriftliga källor ... 41

Personlig kommunikation ... 43

Bilagor ... 44

Bilaga 1. Taggningsmall ... 44

Bilaga 2. Artikelmall – instruktionsartikel – Version 1 ... 45

Bilaga 3. Artikelmall – instruktionsartikel – Version 2 ... 46

Bilaga 4. Artikelmall – felsökningsartikel – Version 1 ... 47

Bilaga 5. Artikelmall – felsökningsartikel – Version 2 ... 47

Bilaga 6. Testperson 1 – Resultat instruktionsmall ... 48

Bilaga 7. Testperson 1 – Resultat felsökningsmall ... 48

Bilaga 18. Förväntat resultat - Användartest – Felsökningsartikel ... 54

Bilaga 19. Förväntat resultat - Användartest - Instruktionsartikel ... 55

Bilaga 20. Bilden som implementerades i användartestet på instruktionsartikeln ... 56

Bilaga 21. Mötesrutiner för rekommenderat avdelningsmöte ... 56

Bilaga 22. Rutin: Skapa artiklar ... 57

Bilaga 23. Rutin: Publicera artiklar ... 57

Bilaga 24. Rutin: Begränsa åtkomst/gör offentlig ... 57

Bilaga 25. Rutin: Välj artikelrubrik ... 58

Bilaga 26. Rutin: Tagga dokument ... 58

Bilaga 27. Rutin: Granska dokument ... 58

(6)

Bilaga 28. Rutin: Uppdatera dokument ... 59

Bilaga 29. Rutin: Arkivera/gallra dokument ... 59

Bilaga 30. Rutin: Uppföljning/statistik ... 59

Figurförteckning

Figur 1, Tillvägagångssätt för taggning. Inspirerad av Agious et. al. (2013) ... 8

Figur 2, Exempel på trädstruktur, Inspirerad av ToggleOn (2010) ... 10

Figur 3, Taggningsområdestäckning med Rydbergs taggningsmetod, Inspirerad av Agious et. al. (2013) ... 17

Figur 4, Regler och riktlinjer för skapande av dokument ... 21

Figur 5, Sammanställning av generella och specifika taggar från del 1 i enkätstudien ... 25

Figur 6, Sammanställning av resultatet från del 2 i enkätstudien ... 26

Figur 7, Sammanställning av statistik från granskning ... 31

Figur 8, Sammanställning av statistik från granskning ... 32

Figur 9, Testperson 4: Instruktion ... 34

(7)

1

1. Inledning

Med dagens snabba internettillväxt är strukturering av data ett måste inom en mängd industrier, då mängden information är väldigt stor. Redan 2003 skrev Blumberg och Atre att hanteringen av ostrukturerade data är ett stort problem inom nästan varje organisation. De skriver att Gartners utredning från samma år visar att kontorsarbetare spenderar runt 30% - 40% av arbetstiden på att hantera dokument. Detta är enligt Blumberg och Atre (2003) en ökning med 20% - 30% sedan 1997, då kontorsarbetare spenderade runt 20% av arbetstiden på hantering av ostrukturerade data.

Den här uppsatsen kommer jämföra tillvägagångssätt för att strukturera ostrukturerade data, och därefter presentera vilket tillvägagångsätt som använts för att strukturera informationen på MSB. Uppsatsen behandlar även utformning av dokumentmallar och rutiner för MSB, vars mål är att hålla dokument enhetliga.

1.1 Studie på MSB

Myndigheten för samhällsskydd och beredskap bedriver verksamhet i Stockholm, Karlstad, Revinge, Sandö och Kristinehamn och har ungefär 850 anställda. De definierar sig själva som en statlig myndighet med uppgift att utveckla samhällets förmåga att förebygga och hantera olyckor och kriser. De har även viktiga uppgifter inom civilt försvar och försöker alltid se till att samhället lär sig av de olyckor som inträffar, så de kan förebygga dem i framtiden. MSB arbetar inte själva inom detta område. De arbetar tillsammans med många andra, t.ex.

kommuner, landsting, myndigheter och organisationer. (MSB, u.å.)

Detta examensarbete är grundat i det exjobb jag utfört hos MSB i Karlstad tillsammans med Nikolai Guldager. Guldager studerar för närvarande tredje året på webb och multimedia programmet på Karlstad Universitet.

1.2 Problembakgrund

Hanteringen av ostrukturerade data ses som ett av de största problemen i dagens IT-industri (Blumberg & Atre 2003). Problemet existerar i olika storlekar då strukturproblem kan uppstå i ett enstaka dokument eller i hur dokument är sparade i förhållande till varandra. Även de dokument som följer en mall kan ha delar som inte följer strukturen (Blumberg & Atre 2003).

Sync NI (2017) skriver i artikeln GDPR: What’s lurking in your unstructured data? att 60- 80% av företagsdata är ostrukturerad. De antyder sedan att detta leder till att det är svårt att veta vad all information är, varför den skapades, vad den innehåller och vilket värde den har för företaget. I artikeln framgår även att en stor utmaning för företag som har mycket ostrukturerade data är risken att de håller data för länge. Dessa problem existerar på MSB. När data inte länge har ett värde för företaget bör den tas bort eller placeras i t.ex. en mapp ämnad för utdaterade dokument.

Fallström (2017), som är min och Guldagers handledare på MSB, skrev i vår uppdragsbeskrivning att MSB i dagsläget tar emot ärenden från myndighetens medarbetare samt externa aktörer. På en normal dag behandlas ca 100 IT-ärenden och 30 samtal. Av de ärenden som kommer in löser kundtjänst ca 60% själva. Resterande ärenden skickas vidare till IT- eller FO-organisationen. (Fallström 2017)

(8)

2 Då ärendena som tas emot är för över 100 olika IT system och varierar i både svårighetsgrad och komplexitet behöver MSBs kundtjänst använda sig utav dokumentation över hur vissa ärenden hanteras. Denna information finns utspridd över flera system och program, såsom OneNote och en gemensam nätverksenhet, vilket gör det svårt för MSBs kundtjänst att veta var de hittar informationen. Det finns även information på MSBs intranät, men den används av någon anledning inte till fullo. (Fallström 2017)

Ett annat problem för MSB är att informationen inte är enhetlig. Det finns för närvarande inte någon rutin att följa när man skapar ett dokument, så innehåll och utformning varierar kraftigt beroende på vem och när informationen skapades. Viss information är även inaktuell då MSB inte har tagit bort äldre dokument, utan istället bara skapat nya. Det kan därför finnas vissa dokument som innehåller information om ungefär samma sak, bara att en är utdaterad.

Informationen kan även vara ofullständig eller fel, då den som skapat dokumentet antingen missförstått hur man löser problemet eller bara skrivit ner delar av lösningen då denne anser att det som inte står där är en självklarhet. Då det inte finns några rutiner eller tekniska hjälpmedel för att hitta inaktuell dokumentation eller för att uppdatera, granska och gallra information är detta ett stort problem. (Fallström 2017)

Det största problemet med MSBs datastruktur är att det inte finns några sökord/taggar eller annan metadata för t.ex. vad som kan visas externt och vad som bör hållas internt, som kan användas för att hitta informationen. Det går heller inte att söka efter information på en plats, då informationen, som nämnt ovan, är utspridd över flera system och program. (Fallström 2017)

1.3. Syfte

1.3.1 Uppdrag från MSB

Uppdraget jag och Guldager tilldelades var att samla alla dokument i ett system, göra dokumenten sökbara och ta bort dubbletter. Vi skulle också skapa en standard för hur de ska hantera, strukturera, skapa och uppdatera information. När en pilot av systemet där dokumenten samlats var färdig, skulle den presenteras till två chefer som tog ett beslut om systemet skulle vidareutvecklas eller inte.

Målet med uppdraget var att minska antalet supportärenden och underlätta för kundtjänsten när de letar efter en lösning på ett problem. Det bör också göra det lättare för nyanställda att lära sig var de hittar allt. Arbetet syftar i första hand på att göra det enklare för handläggare av ärendet att lösa det. Uppdrager är avgränsat till IT-ärenden som kommer in till kundtjänstavdelningen på MSB.

1.3.2 Syfte för kandidatuppsatsen

Syftet med denna kandidatuppsats i ämnet informatik är att avgöra hur MSBs data bör struktureras och hur deras dokument bör hållas enhetliga.

1.3.3 Undersökningsfrågor

1. Hur ska MSBs data struktureras?

2. Hur bör MSBs dokument hållas enhetliga?

(9)

3

1.4 Målgrupp

Uppsatsen vänder sig främst till MSB, men den är även relevant för företag som har problem med ostrukturerade data.

1.5 Avgränsningar

• Arbetet är avgränsat till strukturtillvägagångssätten taggning och trädstruktur då det ska var inom ramen för en kandidatuppsats. Dessa tillvägagångssätt användes på rekommendation av uppdragsgivaren. Rekommendationen grundas i att dessa struktureringstillvägagångssätt är två av de största. Detta betyder att forskningsfråga 1 avgränsas till taggning och trädstruktur.

• På begäran av MSB ska dokumentens enhetlighet grundas i dokumentmallar och rutiner för hur arbetet ska utföras. Detta betyder att forskningen kring undersökningsfråga 2 avgränsas till hur deras dokument bör struktureras för att de ska hållas enhetliga, samt vilka rutiner som ska följas för att dokumenten ska hållas enhetliga.

1.6 Etiska överväganden

Då en enkätstudie och ett användartest utförts måste hänsyn tas jämtemot det grundläggande individskyddskravet. Detta krav består enligt Vetenskapsrådet (2002) av fyra allmänna huvudkrav. Det första kravet är informationskravet. Kravet innebär enligt Vetenskapsrådet (2002) att ”Forskaren skall informera de av forskningen berörda om den aktuella forskningsuppgiftens syfte.” De nämner även att det ska förtydligas att deltagande är frivilligt, samt att deltagare har rätt att avbryta sin medverkan om de inte längre vill delta i studien. Detta klargjordes för alla deltagare i de utförda studierna innan de påbörjades.

Samtyckeskravet är nästa huvudkrav som Vetenskapsrådet (2002) nämner. De definierar det följande ” Deltagare i en undersökning har rätt att själva bestämma över sin medverkan.” I de utförda studierna möttes kravet med ett medgivande där deltagarna fick ge samtycke till deltagande i undersökningen.

Tredje kravet Vetenskapsrådet (2002) tar upp är konfidentialitetskravet. De definierar det följande ” Uppgifter om alla i en undersökning ingående personer skall ges största möjliga konfidentialitet och personuppgifterna skall förvaras på ett sådant sätt att obehöriga inte kan ta del av dem.” För att möta detta huvudkrav har samtliga medgivanden placerats på en säker plats, och alla deltagares personuppgifter uteblir från studien. Det är alltså endast resultatet som presenteras i rapporten.

Avslutningsvis nämner Vetenskapsrådet (2002) nyttjandekravet. Kravet definieras följande

”Uppgifter insamlade om enskilda personer får endast användas för forskningsändamål.”

(Vetenskapsrådet, 2002). Detta förmedlas till studiedeltagarna innan testerna påbörjas.

(10)

4

1.7 Begrepp

Agent: En person som löser ärenden på MSBs kundtjänstavdelning

Folksonomi: System som använder kollaborativ ostrukturerad taggning (Agius et. al.

2013)

Homonym: Ett ord som används för att beskriva två eller fler ord kallas för homonym (Hoffer et.al. 2014). Ett exempel på en homonym är Java. Det kan antingen vara ett programmeringsspråk eller ett kaffemärke.

Individuell taggning: En användare lägger till taggar/metadata i form av nyckelord.

IT: Informationsteknologi (Blumberg & Atre 2003)

Kollaborativ taggning: Kollaborativ taggning beskriver processen av att flera användare kan lägga till metadata/taggar i from av nyckelord till delat innehåll.

Kunskapsbas: Lagringsplats för data Lokalt: Finns bara inom företaget Metadata: Data som beskriver data

Molnbaserat: IT-tjänst som tillhandahålls över internet

MSB: Myndigheten för samhällsskydd och beredskap (MSB u.å.)

Ostrukturerad taggning: Ostrukturerad taggning innebär att den som taggar får välja fritt hur den vill tagga. Det finns inga bestämda fält som måste fyllas i, eller specifika taggar som måste ha ett värde.

PureService: Ärendehanteringssystem för IT som MSB använder i dagsläget (Fallström 2018)

Social taggning: Se Ostrukturerad taggning

Strukturerad taggning: Strukturerad taggning innebär att taggarna har förbestämda kategorier, t.ex. informationsägare. När man då taggar informationen kommer alla dokument och all information ha samma utgångspunkt, vilket minskar sannolikheten att man missar en tagg.

Synonym: Två olika ord som används för att beskriva samma ord (Hoffer et.al. 2014).

Exempel: Epost och mejl.

Tagg: I informationssystem används taggning som ett nyckelord för att beskriva en informationssamling, såsom ett dokument. En tagg kan även beskrivas som metadata som underlättar för användare att hitta samma information igen. (Berendt et. al. 2007)

(11)

5

2. Teori kring strukturering av data

Kapitlet presenterar en litteraturöversikt och behandlar sedan teori kring olika tillvägagångssätt för att strukturera data och vilka för- och nackdelar de har.

2.1 Litteraturstudie

Efter utförande av en litteraturstudie har jag funnit ett antal digitala källor i form av webbsidor och vetenskapliga artiklar om taggning, trädstrukturer, dokumentstruktur och strukturering av data. Det första sökområdet var ostrukturerade data och de problem som kan medföras. De söktermer som användes är ”Unstructured data”, ”Problems unstructured data” och ”pros and cons unstructured data”. Dessa sökningar gjordes i Google Scholar och i vanliga Googlesökningar. Informationen om ostrukturerade data presenteras i inledningen för att beskriva varför ett sånt här arbete är nödvändigt.

När tillräckligt med information hittats gällande ostrukturerade data letade jag efter information om taggning, då det var det första struktureringstillvägagångssätt som Fallström och jag kom fram till skulle beaktas. Till att börja med sökte jag på ”data structure”, ”tagging”,

”keywords” och ”metadata”, vilket gjorde att jag hittade nya söktermer som t.ex. ”structured tagging”, ”unstrutured tagging”, ”collaborative tagging” och ”individual tagging”. Dessa söktermer användes en och en, och jag hittade en sida som kombinerade de olika tillvägagångssätten två och två. Sökningarna gav även fler söktermer såsom ”folksonomy”,

”social tagging” och ”Del.icio.us”. Sökningarna utfördes även här i Google Scholar och vanliga Googlesökningar, men utöver det användes också diva-portal (Digitala Vetenskapliga Arkivet).

Vid taggning är synonym- och homonymkontroll centrala begrepp, så jag sökte även på

”tagging synonyms” och ”tagging homonyms”.

Därefter gjordes sökningar för att hitta information om trädstrukturer, eftersom trädstrukturer är ett vanligt sätt att strukturera filer i datasystem, och för att det är det andra struktureringstillvägagångssättet som uppdragsgivaren ansågs skulle beaktas. De söktermer som användes var ”tree data structure”, ”taxonomy”, ”hierarchy data structure”, ”cluster”, ”map structure” och “mutable and immutable tree structure”. Då nästan all forskning kring trädstrukturer är programmeringsrelaterade var det svårt att hitta forskning kring dokumentstrukturering med trädstruktur. Därför en YouTube videos använts som källa. Källan har granskats och de som skapat videon har många som följer dem och de har massa kommentarer om hur lärorika deras videor har varit. De har dessutom inte använts för att motivera ett val, utan endast för att förklara funktionalitet.

Avslutningsvis sökte jag på ”structure document” och ”how to create a user manual”. Även här användes Googles vanliga sökmotor, samt Google Scholar. Resultatet blev en forskningsartikel och en artikel i hur ett dokument bör struktureras (skrivet av en forskare), samt en WikiHow manual som bedömts till trovärdig genom användarfeedback och jämförelse med vad forskarna sagt inom området. För att få mer inspiration till hur ett dokument bör struktureras analyserades Microsoft (2018) och Atlassians (2018) instruktionsmanualer. All analyserad teori krig hur dokument ska struktureras förmedlar liknande förhållningssätt, och i min litteraturstudie har inga motsägelser uppkommit. För att slippa återupprepning presenteras endast tre källor.

(12)

6

2.2 Tillvägagångssätt för att strukturera data

Det finns ett flertal tillvägagångssätt för att strukturera data. Nedan presenteras några tillvägagångssätt som övervägs att användas vid struktureringen av data på MSB.

2.2.1 Taggning

I informationssystem används taggning som ett nyckelord för att beskriva en informationssamling, såsom ett dokument. En tagg kan även beskrivas som metadata som underlättar för användare att hitta samma information igen. (Berendt et. al. 2007)

Det finns olika typer av taggning. Nedan beskrivs för och nackdelar med de olika tillvägagångssätten för taggning, och avslutningsvis förklaras användningsområden för kombinationer av dessa tillvägagångssätt.

2.2.1.1 Kollaborativ taggning vs individuell taggning

Golder och Huberman (2006) skriver i sin artikel ”The Structure of Collaborative Tagging Systems” att kollaborativ taggning är mest användbar när det inte finns någon som har rollen som bibliotekarie, eller när det finns väldigt mycket information. I artikeln presenteras även en studie på den kollaborativa taggningen på webbapplikationen del.icio.us, och Golder och Huberman (2006) har efter en observation dragit slutsatsen att användandet av kollaborativ taggning skapar en större variation av taggar. Den andra slutsaten Golder och Huberman (2006) drog är att användare vid kollaborativ taggning oftast taggar data för sig själva, utan att tänka på vad andra söker på. De följer upp denna slutsats med att skriva ”Nevertheless, even information tagged for personal use can benefit other users”. Golder och Huberman (2006) skriver även att minoritetsåsikter kan koexistera med de populära åsikterna om vilka taggar som bör användas, utan att påverka sökresultat negativt, vilket är viktigt när flera användare har möjlighet att tagga data.

Bateman (2007) har en blandad syn på kollaborativ taggning. Han anser att tillvägagångssättet erbjuder en simpel och effektiv lösning för att organisera personlig information, men antyder även att kollaborativ taggning är framtaget i flera iterationer av utveckling istället för genom en vetenskaplig- eller designingenjörsprocess. Detta anser Bateman (2007) leder till att vi vet väldigt lite om hur kollaborativ taggning kan appliceras i nya situationer och applikationer, och hur det kan utvecklas. Bateman (2007) skriver också att empiriska studier av taggningssystem visar att oavsett hur simpelt systemet än är för användaren så är det ändå komplext och vidare studier behöver utföras.

Agius et. al. (2013) anser att dynamiken av kollaborativ taggning skiljer sig från dynamiken i en individuell taggningsmiljö. De skriver att kollaborativ taggning tillåter parallell taggning, då flera personer har möjlighet att tagga samma data samtidigt. Detta parallellarbete möjliggör för användare att fokusera på taggning för en del av programmet och överlåta de andra delarna av programmet till andra användare. Agius et. al. (2013) vill även lyfta fram att kollaborativ taggning stöder faktumet att användare som bor i olika tidszoner har möjlighet att arbeta vid olika tidpunkter. Avslutningsvis påpekar Agius et. al. (2013) att flera användare tillsammans åstadkommer mer än en enskild användare, och att kollaboration tillåter användare att rätta varandras misstag samt lägga till de taggar en användare missat att lägga till.

(13)

7 Macgregor och McCulloch (2005) anser att det finns många problem med kollaborativa taggningssystem, t.ex. låg precision och saknad av samlokalisering, som grundar sig i saknaden av kontrollerade vokabulär. De anser dock att kollaborativa taggningssystem inte ska tas bort eftersom bibliotekarier och informationsexperter kan lära sig mycket från de interaktiva och sociala aspekterna som exemplifieras av kollaborativa taggningssystem. Avslutningsvis antyder Macgregor och McCulloch (2005) att den framtida samexistensen av kontrollerade vokabulär och kollaborativ taggning är förväntad.

2.2.1.2 Strukturerad vs ostrukturerad taggning

Det finns både för- och nackdelar med både strukturerad och ostrukturerad taggning, och båda har sina användningsområden. Bar-llan et. al. (2008) har utför en fallstudie där deltagarna delades upp i två grupper. Båda grupperna analyserade bilder relaterade till Israel och judiska kulturarv. Den första gruppen utförde strukturerad taggning genom att placera ut förutbestämda taggar på alla bilder, medan den andra gruppen använde sig av ostrukturerad taggning genom att tagga bilderna med fritextvärden till förbestämda metadata element. (Bar-llan et. al. 2008)

Resultatet som framkom visar att strukturerad taggning vanligtvis resulterar i en mer detaljerad beskrivning än ostrukturerad taggning. Det visar också att vissa taggar kan vara otydliga, vilket leder till att deltagarna missuppfattar taggarna. Avslutningsvis lyfter Bar-llan et. al. (2008) fram att den största fördelen med ostrukturerade taggar är att de inte begränsar användare, samt att de låter användaren tagga genom associationer.

Golbeck et. al. (2011) håller med Bar-llan om att strukturerad taggning ger en mer detaljerad beskrivning. De anser dock att vi måste ge tilltro till ostrukturerad taggning eftersom det bidrar med en större bredd, vilket är mer användbart vid utveckling av en framgångsrik sökalgoritm.

Golbeck et. al. skriver “Many studies have shown that, although professionals cannot be replaced, social tags enhance the description of images for users and provide data useful for retrieval.”

Matusiak (2006) är på samma sida som Golbeck et. al., och framhäver att ”social tagging can enhance the professional index as some of this terminology feels more accessible to the average user.” Poängen är att fria taggar har en terminologi som gör det lättare för en vanlig användare att hitta det den letar efter.

2.2.1.3 Kombinationer av tillvägagångssätt

Taggningsmetoder är olika i olika sammanhang. Som nämnt ovan används både strukturerad, ostrukturerad, individuell och kollaborativ taggning. Olika applikationer, hemsidor, etc.

använder sig av olika kombinationer av dessa taggningsmetoder. Några exempel presenteras i Figur 1 nedan.

(14)

8

Figur 1, Tillvägagångssätt för taggning. Inspirerad av Agious et. al. (2013)

2.2.1.3.1 Individuell ostrukturerad taggning

Individuell ostrukturerad taggning innebär att en person skapar och underhåller taggarna. Dessa taggar har ingen struktur och är ofta bara en samling nyckelord, utan någon tanke på kategorisering. Ett exempel på denna taggningstyp är YouTube. YouTube låter användarna lägga upp videos där de har möjlighet att skriva en beskrivning och välja sina egna taggar/sökord. Efter att användaren laddat upp videon är det fortfarande omöjligt för andra användare att lägga till taggar på den. (Agius et. al. 2013)

2.2.1.3.2 Individuell strukturerad taggning

Detta tillvägagångssätt är likt det ovannämnda i det att det endast är en person som lägger till och modifierar taggar. Skillnaden är att det här tillvägagångssättet använder sig av strukturerade taggar och generellt sätt använder sig av ett standardiserat schema. De system som använder sig av individuell strukturerad taggning är enskilda system som sällan är webbaserade. Ett exempel på individuell strukturerad taggning är ett Windows Media Player plug-in som lägger till stöd för att skriva och läsa taggar från MPEG-4, FLAC, Vorbis och WavPack filer. (Agius et. al. 2013)

2.2.1.3.3 Kollaborativ ostrukturerad taggning

Kollaborativ ostrukturerad taggning är motsatsen till individuell strukturerad taggning. Vid detta tillvägagångssätt skapas och modifieras taggarna av flera användare som arbetar tillsammans genom ett onlinebaserat webbsystem. Taggarna i detta tillvägagångssätt är, precis som i individuell ostrukturerad taggning, ostrukturerad. IMDB är ett exempel på en onlinedatabas som använder sig av kollaborativ ostrukturerad taggning. IMDB låter användarna delta genom att modifiera redan existerande metadata. Dessa taggar är ostrukturerade och måste godkännas av IMDB administratörer innan de placeras i databasen. (Agius et. al. 2013)

(15)

9

2.2.1.3.4 Kollaborativ strukturerad taggning

Kollaborativ strukturerad taggning är enligt Agius et. al. (2013) potentiellt det mest kraftfulla sättet för multimediataggning. Tillvägagångsättet innebär att flera användare interagerar och taggar data inom ett företag. Denna typ av taggning är strukturerad och typiskt sett baserad på ett standardiserat metadata schema. Tillvägagångssättet används vanligtvis i onlinesystem som har en förmåga att hantera ett virtuellt kontaktnät. Ett exempel på en webbapplikation som använder kollaborativ strukturerad taggning är Video-Wiki. (Agius et. al. 2013)

2.2.1.4 Homonymer och synonymer

Vid sökning i ett system som använder taggning är det en stor fördel om homonymer för taggar hanteras. Genom att hantera homonymer tillåts användaren att söka utan att det uppstår meningskrockar, vilket leder till ett mycket bättre sökresultat. Ett exempel på homonym som Macgregor och McCulloch (2006) tar upp är Java. Java är både ett programmeringsspråk, ett kaffemärke och namnet på en ö.

Macgregor och McCulloch (2006) hävdar dock att homonymer för kollaborativa taggar i dagsläget inte går att hantera. De skriver “No control is exerted in collaborative tagging systems over synonyms or near‐synonyms, homonyms and homographs, and the numerous lexical anomalies that can emerge in an uncontrolled environment. The probability of noise in a user's result set is therefore very high.” Av citatet framgår även att synonymer inte går att hantera för kollaborativtaggning.

Farkas (2007) skriver att synonymer är ett problem för kollaborativ taggning. Han följer dock upp med att skriva ”Users may not think of all the possible synonymous terms when tagging an item, but they might add the synonym when the manager makes it easy to do so.”

(Farkas 2007) Farkas syftar på att användarna av ett system med kollaborativ taggning i efterhand har möjlighet att gå in och lägga till en tagg ifall det behövs.

Tingborn (2015) håller med Farkas om synonymproblemet och skriver ”Ett problem är att taggning (eller snarare folksonomi) saknar synonymkontroll vilket betyder att om man i en vanlig taxonomi söker på trollkarl får man upp alla ord som är taggade med häxmästare och magiker. I ett taggningssystem saknas denna funktion och därför går man miste om objekt med dessa taggar”

Matusiak (2006) presenterar en annan vinkel till problemet med synonymhantering. Hon hävdar att problemet beror på social taggning och skriver: ”Some of these features, such as the lack of synonym control or use of singular and plural indicate the limitations of social classification for retrieval purposes. Several researchers point out the messy, “jumbled,” or

“sloppy” nature of social tagging, especially when compared with formal classification systems.” Två ytterligare forskningsartiklar där forskare hävdar detta är Guy and Tonkins (2006) artikel Folksonomies: tidying-up tags? och Hammond et. al. (2005) artikel Social bookmarking tools (I): a general review.

(16)

10

2.2.2 Trädstruktur

Mycodeschool (2014) definierar trädstruktur som en samling entiteter som kallas noder.

Noderna är länkade till varandra för att simulera en hierarki. Till skillnad från taggning som är linjär datastruktur, är trädstrukturen ickelinjär.

Figur 2, Exempel på trädstruktur, Inspirerad av ToggleOn (2010)

I en trädstruktur heter den noden som ligger högst upp rot. I figur 2 ovan är A roten i strukturen.

Roten leder ofta till minst två barnnoder som i sin tur ofta har egna barnnoder. Alla dessa noder innehåller någon form av data, och denna data har ingen bestämd datatyp. (mycodeschool 2014) Det som gör trädstrukturen användbar är enligt Schmit (2005b) att det är lätt att skapa och ta bort mappar. Även om en fil befinner sig djupt ner i en trädstruktur är det inga svårigheter att ta bort den. På sin föreläsning om Tree data structures tar Schmit (2005b) även upp att en trädstruktur naturligt kan växa för att hålla en oändligt mängd objekt.

2.2.2.1 För- och nackdelar med trädstruktur

Det finns ett antal för- och nackdelar med att strukturera data med trädstrukturer. En fördel med trädstrukturering av data är att de existerande träden är lätta att sätta ihop till ett större träd.

Schmit (2005b) skriver “Of course, it is always easy to build a new tree using smaller trees that we have already constructed”. Han följer dock upp med att skriva “But the situation get more interesting if we wish to add new ‘growth’ in place of one of the leaves already embedded within a tree.” Med detta menar Schmit (2005b) att det ibland uppstår problem när ett löv blir en nod.

En nackdel med trädstrukturer är att vissa dokument går att placera i två eller fler mappar.

(Golder & Huberman 2006). Ett exempel på detta är solrosfrön. Solrosfrön passar i både mappen frön och i mappen snacks. Detta innebär att solrosfrön antingen måste placeras i båda mapparna, eller att de bara finns i en av dem. Placeras solrosfrön endast i en av mapparna försvårar det för användaren när denne vill hitta information om solrosfrön. Nicol et. al. (2007) håller med Golder och Huberman (2006) och skriver att användandet av kollaborativa trädstrukturer för att strukturera data ibland skapar problem då olika arbetslag ibland vill placera

(17)

11 dokument på olika platser i trädstrukturen. De skriver också att “there might be tensions between the knowledge structures created by one team and the knowledge structures that are guiding the thinking of the team accessing these resources” och menar att det arbetslag som ska använda den data som lagrats i trädstrukturen ibland inte hittar det de letar efter. Detta då arbetslagen resonerat annorlunda gällande placeringen av data i trädstrukturen.

2.2.2.2 Föränderliga träd vs oföränderliga träd

Schmit (2005a) skriver att huvudanledningen till användning av föränderliga träd är att undvika konstruktion av ett flertal nya noder vid borttagning eller tillägg av element. Schmit (2005a) styrker sedan att nodborttagning blir mycket enklare. Schmit (2005b) påpekar även att föränderliga träd är bättre vid trädbalancering, vilket innebär att en ny rot installeras i hierarkin.

Föränderliga träd har en kortlivad datastruktur enligt Driscoll et. al. (1989).

Oföränderliga träd fungerar väldigt annorlunda från föränderliga träd. Enligt Schmit (2005b) är ett viktigt aspekt med oföränderliga träd att de skapar nya träd istället för att modifiera det aktuella. När en ändring sker skapas ett nytt träd som är väldigt likt det förra, men innehåller ändringen. Detta är enligt Driscoll et. al. (1989) en beständig datastruktur, då den tillåter tillgång till både den nya och den gamla versionen när som helst. Denna typ av struktur används i t.ex.

notepad. När du gör ändringar i notepad har du, fram till och med du sparar, tillgång till en äldre version.

Sammanfattningsvis är föränderliga trädstrukturer bättre ifall ändringar som t.ex.

borttagningar eller trädbalanceringar sker ofta, medan oföränderliga trädstrukturer är bättre när det måste finnas möjlighet att gå tillbaka till tidigare version utan större problem.

2.3 Strukturering inom dokument

Då enhetligheten för dokumenten avgränsats till att skapa mallar och rutiner kommer detta kapitel handla om hur ett dokument bör vara strukturerat. Denna information kommer användas till grund för att skapa mallarna och rutinerna. Största vikten läggs på instruktionsartikelskrivande då majoriteten av de dokument som används är instruktioner.

2.3.1 Förhållandesätt vid skapande av dokument

En artikel går att skriva på många olika sätt. Brown (1989) tar upp ett antal förhållandesätt till hur en artikel ska skrivas i sin vetenskapliga artikel Standards for Structured Documents. Några av de förhållandesätt Brown lyfter fram är:

• Bilder ska ha en vinkel som är 0ô, 90ô, 180ôeller 360ô

• Font, teckenfärg och teckenstorlek ska vara bestämda för rubriker och styckestext

• Bilderna ska ta upp så lite plats som möjligt så länge det går att se vad de föreställer

• Upplägget i dokumentet ska vara logisk. Rubriker och instruktioner ska finnas där du förväntar dig att de ska vara.

Dessa förhållandesätt från 1989 är relevanta än idag. WikiHow (2018) framhäver även de att logiken i strukturen är väldigt viktig, samt att det är viktigt att tänka på val av font, teckenfärg och teckenstorlek. De bidrar även själva med ett antal viktiga förhållningssätt till instruktionsskrivande.

(18)

12 Det första steget i utvecklingen av en instruktionstext är enligt WikiHow (2018) att identifiera vilka som kommer använda instruktionerna. De aspekter som måste tas hänsyn till vid identifiering av användare är vart de kommer vara när de läser instruktionerna, hur ofta en instruktion används och hur mycket erfarenhet användarna har inom ämnet. När instruktionerna sedan skrivs är det, som nämnt ovan, enligt WikiHow (2018) och Brown (1989) viktigt att tänka på logiken. Alla användare ska kunna förstå instruktionerna, samt hitta det de letar efter utan några större problem. För att fler användare ska uppfatta instruktionerna rekommenderar WikiHow (2018) att författaren undviker tekniska termer. Självklart finns det situationer där det inte går att undvika, men där det går bör de undvikas (WikiHow 2018).

Användning av steg för steg redovisning av instruktioner är också något som starkt rekommenderas av WikiHow (2018). Det gör att varje aktivitet som utförs presenteras separat, vilket gör instruktionen lättare att följa. Detta rekommenderas även av Hodgson (2007), som doktorerat och forskar inom användbarhet. Hodgson (2007) visar i artikeln ”Tips for writing user manuals” att det finns flera sektioner av en instruktionsdokumentstruktur och att alla bör tas hänsyn till. Den första sektionen beskriver de generella riktlinjerna. Här presenteras riktlinjer såsom att dela upp instruktionen i steg för steg beskrivningar och att instruktionerna bör utsättas för ett användartest där vissa deltagare dessutom bör ha någon typ av handikapp, t.ex. färgblind.

Hodgson (2007) hävdar att ett bra första intryck är viktigt i den andra kapitlet med sektionsriktlinjer. Han skriver ”Many users never actually get as far as the user manual. It is often tossed aside as being either secondary, or just too difficult to deal with. When this happens, the user, the product and the writing team all suffer in some way. In order to get past this point the user manual must make a strong and positive first impression.” Hodgson (2007) föreslår korta instruktioner och en ren och lättläst font för att uppnå ett bra första intryck.

Det är inte bara ett dåligt första intrycket som gör att användare blir irriterade. En andra faktor som irriterar användarna är svårigheten att hitta det de letar efter. Hodgson (2007) skriver att det är viktigt att organisera både hur instruktionerna förhåller sig till varandra, samt hur instruktionerna är skrivna. Som lösning på problemet föreslår Hodgson (2007) en hierarkisk organisering av informationen och att nyckelord placeras på de olika instruktionerna för att snabbt söka upp ett dokument. Hodgson (2007) hävdar dock att alla synonymer ska gå att söka på för att hitta en instruktion genom ett nyckelord. Avslutningsvis föreslår Hodgson (2007) att det ska finnas en sektion för felsökning.

Hodgson (2007) lyfter också fram riktlinjer för hur en instruktion bör skrivas för att göra instruktionerna lättförståeliga. Detta är enligt Hodgson (2007) den viktigaste delen med en instruktion eftersom ”It is critical that the instructions are easy to read and are understandable by all users. Many user manuals have instructions that are incomplete, incorrect, or simply have no bearing on the actual product.” De riktlinjer Hodgson (2007) rekommenderar är väldigt lika de som både Brown (1989) och WikiHow (2018) lyfter fram. Riktlinjer som än inte nämnts som Hodgson (2007) tar upp är exempelvis presentation av ikoner och symboler tidigt i texten, samt att författaren inte ska anta att användaren har någon tidigare kunskap inom området.

Hodgson (2007) rekommenderar även att författaren av instruktionerna ska utföra alla steg samtidigt som de skrivs ner.

(19)

13

2.4 Precisering av forskningsfrågor

Forskningsfrågor:

1. Hur ska MSBs data struktureras?

2. Hur bör MSBs dokument hållas enhetliga?

Då enhetligheten avgränsats till att lösas med mallar och rutiner bör den forskningsfrågan omformuleras till ”Hur ska mallar och rutiner utformas för att MSBs dokument ska hållas enhetliga”. På förfrågan av uppdragsgivaren har strukturfrågan inskränkts till att gälla taggning. Mer om detta i 3.2.2 Val av tillvägagångssätt. Detta gör att de nya

forskningsfrågorna blir:

1. Vilket taggningstillvägagångssätt ska MSBs data struktureras med?

2. Hur bör mallar och rutiner utformas för att MSBs dokument ska hållas enhetliga

(20)

14

3. Tillvägagångssätt och metodval

Detta avsnitt behandlar det både det vetenskapliga och det praktiska angreppssätt som använts vid forskningen och utförande av examensarbetet. Läsaren presenteras med metodval för strukturering av data, som sker både i hur dokumenten förhåller sig till varandra och hur varje enskilt dokument är strukturerat. Läsaren får även en inblick i hur data samlats in och en motivering till metodvalen.

3.1 Vetenskapligt angreppssätt

Forskningen i detta examensarbete är baserad på olika tillvägagångssätt för att strukturera data, samt hur dokumentstrukturer bör struktureras för att hållas enhetliga. De tillvägagångssätt som analyserats för att strukturera data i teorikapitlet är taggning och trädstrukturering, och för att samla in information om hur dokumenten ska bli enhetliga har dokumentstrukturer och dokumentriktlinjer granskats. Forskningen utfördes för att få underlag till ett beslut om hur den slutgiltiga lösningen på MSB ska se ut ifall systemet vi utför pilot på tas i bruk.

Forskningsstrategin som används för att få fram data är en enkätstudie, ett användartest och informationssökning på webben. Studierna förklaras mer detaljerat under 3.3.1 Enkätstudie och 3.3.3 Användartest - Artikelmallar och taggningsmall.

3.2 Praktiskt angreppssätt

Kapitlet beskriver hur vi valt att gå tillväga för att utföra examensarbetet och behandlar metodval för strukturering av data, både inom dokument och i hur dokument förhåller sig till varandra.

3.2.1 Granskning av gamla dokument

Det första steget i processen var att sätta oss in i hur dåvarande situationen såg ut, samt att få inspiration om hur framtida strukturen kunde skapas. Därför granskades ett stickprov på 72 dokument efter nedanstående tolv punkter. Punkterna är framtagna tillsammans med Guldager.

Då de till en början endast planerades användas för att sätta oss in i dåvarande situation tog ingen beaktning till tidigare forskning gällande granskning.

1. Relevant och tydlig rubrik 2. Är informationen lättförståelig?

3. Är informationen bra strukturerad?

4. Är bilderna tydliga och relevanta för sammanhanget?

5. Informationsstatus (aktuell, inaktuell, ta bort) (allt som är 2 år gammalt räknas som inaktuellt då det bör kontrolleras ifall det fortfarande gäller)

6. Målgrupp (Intern IT Kundtjänst, Extern MSB, Externa aktörer)

7. Vem äger/ansvarar för informationen? / vilken funktion äger den här informationen (t.ex. kundtjänst)

(21)

15 8. Vilka dokument är lika det här dokumentet/Kan informationen i dokumentet slås ihop

med information från ett annat dokument?

9. Ska vi slå isär dokumentet? För mycket info i ett dokument.

10. Typ av dokument? (Q&A/instruktion, allmän info/slask, rutin) 11. Förslag på taggar/sökförslag/vad gäller informationen

12. Generella kommentarer (valfri)

Efter att ha granskat ovanstående tolv punkter ansågs resultatet relevant för att motivera förändring från den nuvarande verksamheten. Vi tog därför vi ut statistik på de första fem punkterna för att kunna använda som underlag för pilotdemon som motivation till varför en förändring behövde ske. Analys av statistiken kommer under 5.1 Granskningsstatistik i analyskapitlet.

Kriterierna för att respektive granskningskriterier ska uppfyllas presenteras nedan:

• För att ett dokument ska klassas som att det har en relevant och tydlig rubrik krävs det att rubriken speglar det som dokumentet innehåller, samt att det ska gå att förstå vad dokumentet innehåller från att endast lästa rubriken.

• För att ett dokument ska klassas som lättförståeligt ska det gå att följa instruktionerna utan större svårigheter

• För att ett dokument ska klassas som bra strukturerat ska strukturen vara logiskt upplagd. Text och bilder ska placeras där de förväntas ligga.

• För att en bild ska klassas som relevant och tydlig ska det synas vad som är på bilden, samt att instruktionstexten ska passa ihop med bilden.

• För att informationsstatusen på ett dokument ska klassas som aktuell måste dokumentet ha uppdaterats de senaste två åren.

3.2.2 Val av tillvägagångssätt för datastruktur

Det första steget i processen var att bestämma vilket tillvägagångssätt som passade bäst för att strukturera MSBs dokument i förhållande till varandra. För att underlätta valet av

tillvägagångssätt har fördelar och nackdelar analyserats hos både taggning och trädstrukturer.

3.2.2.1 Taggning vs trädstruktur

Både taggning och trädstruktur hade fungerat bra för att strukturera datan på MSB, men det slutgiltiga tillvägagångssättet blev taggning på grund av tre anledningar.

1. Lagringsutrymme: Vid användning av taggning undviks dubbletter av dokument, vilket kan uppstå vid användning av trädstruktur (Golder & Huberman 2006). Detta är viktigt för MSB eftersom mängden data de har är stor.

(22)

16 2. Lätt att hitta: Placeras ett dokument endast på en plats i en trädstruktur när det går att placera på två eller fler finns möjligheten att användarna vid navigering i en trädstruktur anser att en mapp eller ett dokument är felplacerat i trädstrukturen, vilket gör att de inte hittar det de letar efter (Nicol et. al. 2007). Likartat problem finns med taggning, men det är bättre att ett dokument är felaktigt taggat än att en mapp placerats fel i en trädstruktur.

3. Systembeslut: På beslut av uppdragsgivaren valdes systemet Confluence som system att lagra all data på. Detta eftersom systemet har en direkt koppling till ett ärendehanteringssystem (Jira Service Desk). Confluence strukturerar dokument efter taggar, vilket avgjorde valet av tillvägagångssätt. Systemvalet för den här uppsatsen kommer att förklaras tydligare under 3.2.3 Val av system.

3.2.2.2 Metodval inom taggning

I teorikapitlet presenterades fyra olika taggningstillvägagångssätt för att skapa en struktur i hur dokument förhåller sig till varandra. Det som skiljer tillvägagångssätten är om taggningen utförs av en eller flera personer, samt om taggningen har bestämda ord som används eller om alla taggar väljs helt fritt. Då flera personer på MSB behövde ha möjlighet att skapa och tagga dokument måste därför ett kollaborativt tillvägagångssätt användas. Genom att eliminera de tillvägagångssätt som inte tillåter ett kollaborativt arbetssätt finns det endast två tillvägagångssätt att välja mellan. Dessa är kollaborativ strukturerad taggning och kollaborativ ostrukturerad taggning.

Kollaborativ strukturerad taggning tvingar agenterna att fylla i vissa bestämda taggar, vilket gör att alla agenter kommer använda samma böjning och tempus på taggarna. Nackdelen är dock att vissa artiklar kan vara svåra att placera en tagg på, då utbudet av taggar är begränsat.

Det finns inte alltid en tagg som fungerar. En fördel med kollaborativ strukturerad taggning är att taggarna ger en mer specifik beskrivning (Bar-Ilan et. al. 2008 och Golbeck et. al. 2011).

Den största fördelen med ostrukturerade taggar är att de inte begränsar användare, samt att de låter användaren tagga genom associationer (Bar-Ilan et. al. 2008). Matusiak (2006) framhäver också att poängen med fria taggar är att de har en terminologi som gör det lättare för en vanlig användare att hitta det den letar efter.

Då de båda tillvägagångssätten har sina för- och nackdelar har en ny metod som blandar de båda utformats. Den nyskapade metoden heter Rydbergs taggningsmetod och är, utöver de kollaborativa taggningsmetoderna som nämnts ovan, inspirerad av Panosfkys bidrag i Panofsky–Shatford matrixen för kategorisering av taggar. Täcknignsområdet för Rydbergs taggningsmetod visas i figur 3.

(23)

17

Figur 3, Taggningsområdestäckning med Rydbergs taggningsmetod, Inspirerad av Agious et. al. (2013)

Panofskys bidrag i matrixen är tre kategorier som används för att kategorisera taggar. Dessa tre kategorier är enligt Golbeck et.at. (2011):

1. Generell 2. Specifik 3. Abstrakt

Golbeck et. al. (2011) antyder att den generella kategorin inkluderar generella saker, personer och event, t.ex. hund, vår och källare. De skriver även att den specifika kategorin är mer specificerad än den generella taggen, t.ex. björk. Den generella taggen ”träd” kan vara vilket träd som helst, medan den specifika taggen ”björk” specificerar vilken typ av träd det är.

Avslutningsvis skriver Golbeck et. al. (2011) att den abstrakta taggen är en mindre konkret beskrivning. Taggar i denna kategori är t.ex. mytiska varelser, exempelvis enhörningar, eller känslor, exempelvis kärlek.

Rydbergs taggningsmetod använder den generella kategorin och den specifika kategorin för att få fram användandet av strukturerade taggar. Det som skiljer Rydbergs taggningsmetod från Panofskys bidrag i Panofsky–Shatford matrixen för taggning är den sista kategorin. I Panofkys version anges en tagg inom den abstrakta kategorin, medan Rydbergs taggningsmetod har en kategori för fria taggar. Tanken var att agenterna som använder taggningssystemet på MSB ska ange så många relevanta ostrukturerade taggar de kommer på som fria taggar. Genom att använda två strukturerade taggar, en generell och en specifik, och flera ostrukturerade taggar (fria taggar), bör sökningen på dokument i Confluence underlättas.

Ytterligare en skillnad finns mellan Panofskys version och Rydbergs taggningsmetod, och det är hur taggarna ska anges. Panofsky tillåter användandet av flera ord vid taggning inom de olika kategorierna, medan Rydbergs taggningsmetod endast tillåter ett ord per tagg. Detta är då de system som piloten avser att testa endast tar ett ord per tagg. Taggningsmetoden är alltså specificerad för Confluence och Jira Service Desk.

3.2.2.3 Synonymhantering vid användning av Rydbergs taggningsmetod

Rydbergs taggningsmetod använder sig delvis av strukturerade taggar, vilket betyder att dessa taggar finns förbestämda i en specifik form. Då agenterna som taggar dokumenten endast får

(24)

18 använda sig av dessa taggar när de ska ange en generell eller specifik tagg kommer synonymproblem aldrig uppstå för dessa taggar. De förbestämda taggarna är framtagna i en enkätstudie och de finns presenterade i figur 5 senare i dokumentet.

För de fria taggarna i Rydbergs taggningsmetod finns ingen synonymhantering. Istället rekommenderas agenten tagga de synonymer den kommer på, för att sedan i efterhand lägga till de taggar de märker saknas. Detta är en av fördelarna med kollaborativ taggning enligt Farkas (2007).

3.2.3 Val av system

På beslut av MSB kommer systemen Jira Service Desk och Confluence att användas för att smala all data på en plats. Beslutet grundar sig i att ärendesystemet Jira Service Desk har en direkt koppling till kunskapsbasen Confluence. Det innebär att en agent, istället för att lösa ett ärende själv, ibland bara behöver skicka en länk till ett dokument som placerats i Confluence på hur ärenderapportören kan lösa ärendet själv. Ytterligare en anledning till systemvalen är funktionaliteten som existerar i de båda systemen. Jira Service Desk har betydligt mer funktionalitet än vad det dåvarande ärendehanteringssystemet (Pureservice) hade. Som resultat av den nya funktionaliteten kommer många arbetsuppgifter som då utfördes på papper ha möjlighet att digitaliseras.

3.2.3.1 Konfiguration av Jira Service Desk och Confluence

Jira service Desk och Confluence installerades båda i MSBs testmiljö efter att beslutet för att utföra pilot på systemen tagits. Uppföljningen på installationen var konfigurering av de båda systemen. Det krävdes mycket konfigurationer för att systemens funktionalitet och utseende skulle vara som MSB ville ha det. Ändringar som utfördes i Jira Service Desk var t.ex. skapa köer för olika ärendetyper och implementera gruppfunktionalitet, och ändringar som utfördes i Confluence var redigering av två existerande mallar för att underlätta skapande av dokument samt för att hålla dokumentens struktur enhetlig.

Under konfigurationens gång implementerades åtta plug-ins för att möjliggöra funktionalitet som inte finns tillgänglig i originalversionerna av de båda systemen. Ett exempel på plug-in som använts är Archiving Plugin for Confluence. Detta plug-in möjliggör en arkiveringsfunktion. Arkiveringsfunktionen gör att artikelskapare får ett email när ett av deras inte har ändrats på ett bestämt antal dagar, samt att artikeln arkiveras om den inte uppdaterats på bestämt antal dagar efter att ett email skickats till artikelskaparen.

3.2.4 Framtagning av Dokumentmallar och taggningsmall

När granskningen av dagens dokument var färdig påbörjades en mall för både taggning och dokumentstruktur.

3.2.4.1 Mallutformning

I projektet skapades två Dokumentmallar för att se till att samma struktur hålls i alla dokument av samma typ. De två dokumenttyper som valts att skapa en mall till är instruktionsartiklar, som används för längre instruktioner där flera uppgifter måste utföras, och felsökningsartiklar, som används för korta problem och svar när något inte fungerar som det ska. Dessa två mallar har

(25)

19 skapats för att hålla en struktur i hur alla dokument är upplagda, och har båda baserats på hur Microsoft (2018) och Atlassian (2018) skriver sina instruktioner, hur MSB lagt upp dokument på sitt intranät, tidigare forskning och allmänna guider.

Det skapades även en taggningsmall för att samma taggningsmetod ska användas på alla dokument. Taggningsmallen beskriver vilka taggar som krävs på varje dokument. Mallen är baserad på Rydbergs taggningsmetod och har skapats för att hålla en struktur i hur dokumenten förhåller sig till varandra.

3.2.4.1.1 Artikelmall - Instruktion

Under framtagningen av instruktionsmallen fastnade vi direkt på steg för steg beskrivningar.

Anledningen till detta är att den som läser instruktionerna lätt ska kunna identifiera varje steg i processen, samt att det rekommenderats av Hodgson (2007) och WikiHow (2018). Genom att använda sig av steg för steg beskrivningar bör även tiden för att lösa ett ärende kortas ner i vissa lägen, t.ex. om den som skickat in ärendet löst halva problemet själv och agenten endast behöver gå igenom andra halvan av instruktionerna. Detta är ett system som används av majoriteten av användarmanualerna på webben. Både Atlassian (2018) och Microsoft (2018) använder sig av den här typen av lösning.

När strukturen för steg för steg beskrivningarna togs fram skapades tre förslag på lösningar.

Förslag 1, som också blev den slutgiltiga lösningen, går ut på att dokumentförfattaren skriver ut stegen i en numrerad lista och placerar de bilder som är relevanta till beskrivningarna under texten.

Exempel på Förslag 1:

1. Steg 1 i beskrivningen

(Relevant bild till steg 1 i beskrivningen) 2. Steg 2 i beskrivningen

(Relevant bild till steg 1 i beskrivningen) 3. Osv.

Två stora fördela med ovanstående lösning är att det inte tar lång tid att fylla i en sådan mall, samt att den är stilren och simpel.

Förslag 2 är väldigt tydligt, men mallen tar lite längre tid att fylla i. Strukturen är uppbygg i en tabell med två kolumner där steg för steg beskrivningen är i den vänstra och matchande bild placeras i den högra.

1. Steg 1 i beskrivningen Relevant bild till steg 1 i beskrivningen 2. Steg 2 i beskrivningen Relevant bild till steg 2 i beskrivningen

Osv. Osv.

(26)

20 En fördel med den här typen av beskrivning är att den är mer kompakt, vilket gör att du ofta kan se hela beskrivningen samtidigt och inte behöver skrolla för att hitta var du befinner dig/vart du ska börja. Strukturen är även väldigt tydlig för de som läser dokumentet i efterhand. Det som gjorde att denna lösning valdes bort var att det tog längre tid att fylla i den samt att MSBs kundtjänstavdelning tyckte den tidigare lösningen var mer stilren.

Förslag 3 är en blandning av de två tidigare. Den använder tabellstrukturen som används i andra förslaget, men delar upp alla steg var för sig.

1. Steg 1 i beskrivningen

Relevant bild till steg 1 i beskrivningen 2. Steg 2 i beskrivningen

Relevant bild till steg 2 i beskrivningen

Målet med Förslag 3 var att dela upp så att stegen tydligt presenteras ett i taget, vilket minskar risken för förvirring. Anledningen till att denna valdes bort är samma som ovanstående, den tar längre tid att skapa än det första förslaget.

Innan valet av Artikelmall gjordes presenterades alla tre för MSBs kundtjänstavdelning för att de ska få säga sitt, då det är de som ska använda Artikelmallen i sitt arbete. Efter att de anställda fått möjligheten att uttrycka sina åsikter i en öppen diskussion drogs slutsatsen att det första förslaget på dokumentstruktur passade bäst för MSB.

När ett beslut var taget för hur instruktionerna skulle skrivas implementerades en sektion för beskrivning av dokumentinnehåll precis ovanför steg för steg beskrivningen, samt instruktionstext som beskrev vad som behövde göras för att det skapade dokumentet skulle vara godkänt för publicering. Se bilaga 2 för den första/otestade versionen av instruktionsmallen.

3.2.4.1.2 Artikelmall - Felsökning

När vi skapade felsökningsmallen utgick vi från instruktionsmallen. Samma instruktionstext implementerades i början av dokumentet och fetmarkering samt flerstegsprocesser instruerades att skriva likadant. En felsökningsartikel är dock, till skillnad från en instruktionsartikel, endast ett problem/symptom och ett svar. Då det inte finns så många olika sätt att utforma mallen på skapades en version att användartesta.

Mallstruktur:

Problembeskrivning:

Symptom/felmeddelande:

Lösning:

(27)

21 Tanken med mallen är att agenterna snabbt ska kunna skriva in vad problemet är och hur man löser problemet. Genom att implementera en del för symptom ökar sökningsresultaten när användare söker på de problem som uppstådd. Denna sektion är även ämnad att hålla bilder på relevanta felmeddelanden. Se bilaga 4 för den första/otestade versionen av felsökningsmallen

3.2.4.1.3 Regler och riktlinjer vid skapande av ett dokument

När en agent skriver ett dokument finns ett antal regler och riktlinjer att förhålla sig efter. Dessa regler och riktlinjer existerar för att alla instruktioner ska vara enhetliga och lättförstådda, och är baserade på tidigare forskning samt manualer för hur en instruktion bör skrivas. Reglerna och riktlinjerna framgår i figur 4 nedan

Figur 4, Regler och riktlinjer för skapande av dokument

3.2.4.1.4 Rutin för dokumentation

För att informationen ska hållas uppdaterad har rutiner tagits fram genom ett möte med uppdragsgivaren. Rutinerna har inspirerats från hur MSB vill att arbetet ska utföras, samt de förhållandesätt som tas upp i 2.3.1 Förhållandesätt vid skapande av dokument. Framtagna rutiner beskriver vem som ska utföra en viss handling, när handlingen ska utföras och hur handlingen utförs. Se bilaga 22–30 för alla rutiner. Ett exempel på en sådan handling är uppdatering av artiklar. Se nedan:

Uppdatering av artiklar

Vem: Artikelansvarig

När: Om artikeln inte uppdaterats på ett år (365 dagar) Hur:

1. Läs igenom dokumentet och avgör om den ska vara kvar.

2. Om dokumentet ska vara kvar: Utför nödvändiga ändringar och publicera artikeln på nytt.

3. Om dokumentet inte ska vara kvar: Ta bort dokumentet.

(28)

22 Utöver ovanstående rutiner har även regelbundna avdelningsmöten (se bilaga 21) tagits fram till MSB. På avdelningsmötet ska alla avdelningar som använder systemet gå igenom de dokument som skrivits under veckan. Rutinen grundas i det dåvarande problemet att det inte fanns någon bestämd struktur inom dokumenten.

3.2.4.2 Taggningsmall

Taggningsmallen är baserad på Rydbergs taggningsmetod. Mallen förklarar de tre olika taggningskategorier som ska anges enligt Rydbergs taggningsmetod och presenterar sedan de regler som ska följas när en tagg anges. De regler som framgår i taggningsmallen är följande:

1. Alla taggar ska vara i singular 2. Alla taggar ska vara i nutid

3. Alla taggar ska endast innehålla ett ord

4. Alla dokument/artiklar ska innehålla en generell tagg, en specifik tagg och minst en fri tagg

Taggregel 1 och 2 grundas på att alla agenter ska ange samma ord på samma sätt. Taggregel 3 måste existera då systemet vi testar endast tar taggar som är ett ord. Självklart finns möjligheten att binda ihop ord med t.ex. ett understreck, men då dessa taggar fungerar som söktermer kommer antalet resultat på sökningar minska då ingen binder ihop ord med understreck när de söker i ett sökfält. Taggningsregel 4 grundas i den taggningsmetod som tagits fram för detta projekt.

3.3 Insamling av data

En enkätstudie som utförts för att se hur kundtjänstarbetarna tänker kring taggning, samt ett användartest för att testa de mallar vi utformat.

3.3.1 Enkätstudie

Studien som först utfördes var en kvantitativ enkätstudie. Metoden valdes då undersökningen inte skulle ha någon påverkan från undersökaren, samt att det enkelt går att analysera en stor mängd resultat. Studien bestod av två större frågor som besvarades av fem kundtjänstanställda.

Den första frågan bad testpersonen fylla i minst fem ärenden som är relevanta till olika generella taggar. De generella taggarna är rekommenderade av min och Guldagers handledare på MSB, Johan Fallström, och täcker enligt honom cirka 75% av alla ärenden som kommer in dagligen.

Testpersonerna fick även fylla i om en generell tagg saknades. Saknades en generell tagg fick testpersonen ange den, samt några ärenden som passar in under den generella taggen. De ärenden som fylldes i sammanställdes och motsvarar nu de specifika taggarna.

Del två av enkäten bestod av olika ärenden som testpersonen skulle tagga. Taggningen utgick från Rydbergs taggningsmetod. Målet med andra frågan i enkäten var att se hur testpersonerna använder sig av Rydbergs taggningsmetod, samt att låta testpersonerna använda taggningsmetoden i praktiken, vilket förhoppningsvis leder till att testpersonerna går tillbaka och fyller i mer i första frågan.

(29)

23

3.3.2 Pilotstudie av enkät

Hassan et. al. (2006) skriver att en pilotstudie definieras som liten studie som testar forskningsprotokoll, datasamlingsinstrument och forskningstekniker i förberedelse för en större studie. De skriver även att det är ett av de viktigaste stegen i ett forskningsprojekt och att de utförs för att hitta brister och potentiella problemområden i forskningsinstrumenten.

Då projektet på MSB innehåller en enkätstudie är det lämpligt att pilottesta den först.

Genom att pilottesta undersökningen fastställs det vilka frågor som ställts i pilottestet som kan kvarvara i de skarpa testerna, samt vilka som behöver modifieras.

3.3.2.1 Resultat av pilotstudien

Efter utförd pilotstudie var det tydligt att vissa delar behövde förtydligas. Till att börja med var strukturen förvirrande för testpersonen, vilket ledde till att denne inte visste vart svaren var tänka att skrivas. Det märktes också att taggningsdelen inte gav de resultat som den planerades ge. Det beror till stor del på att upplägget ledde testpersonen i en viss riktning. Resultaten visar även att testpersonen valde att minimera antalet taggar och angav endast de som vart självklara från dokumentnamnet. Testpersonen missade alltså att ange fria taggar på en del dokument.

Ytterligare ett problem som hittades var att ett av dokumenten testpersonen fick tagga var otroligt otydligt och det gick inte att förstå vad som skulle taggas, då det var så blandat innehåll i dokumentet.

Resterande delar av studien fugerade som planerat och gav de resultat vi förväntade oss.

Frågan där testpersonen räknade upp specifika taggar som passar till respektive kategori gav till och med bättre resultat än förväntat. Testpersonen kom till och med fram till att det bör vara en till Generell tagg.

3.3.2.2 Ändringar efter pilotstudien

Efter utförd pilotstudie utfördes ett fåtal ändringar. Till en början skapades en tydligare struktur för att testpersonerna i de skarpa testerna lätt ska veta var de ska skriva svaren. I den andra delen av enkäten där testpersonen ska skriva in taggförslag implementerades en tabell som testpersonen ska fylla i. Detta kommer även göra det svårt för testpersonerna att missa att ange en tagg. Utöver detta tog vi bort taggning för dokumentet datorhantering, då det dokumentet innehöll så mycket blandat innehåll. Huvudkategorin som framkom i pilotstudien togs inte med i de skarpa testerna då enkäten har en fråga om någon huvudkategori saknas. Ifall testpersonerna i de skarpa testerna också anger samma huvudkategori kommer den användas i den slutgiltiga lösningen.

3.3.3 Användartest - Artikelmallar och taggningsmall

Utöver enkätstudien utfördes även ett användartest på de mallar som presenterades under 3.2.4.1 Mallutformning. Metoden valdes för få en inblick i hur agenterna tolkar de mallar som skapats, samt för att få agenternas åsikter om mallarna, då det ände är de som ska använda mallarna i slutändan. Användartestet gick ut på att användaren med hjälp av en taggningsmall, sammanställning av svaren på enkätstudien och ett dokument med regler för hur man skapar ett dokument skulle skapa ett instruktionsdokument och ett felsökningsdokument, och därefter tagga dokumenten med utgångspunkt i taggningsmallen. Båda dokumenten utgick från mallar

(30)

24 som användaren bads fylla i. Användartestet utfördes med sex deltagare och målet med testet var att få underlag till att förbättra alla tre mallarna så att det ska vara lätta att använda och förstå.