Implementering och utbildning 38

Som nämndes i stycke 5.1 är det viktigt med att ett syfte för en implementering av Wiki sätts redan från början. Efter det menar Mader (2008, s.63) att det är viktigt att skapa en test-Wiki, se 3.3.3. Jag menar att hela denna rapport kan liknas vid en test-Wiki, då ingen på företaget tidigare hade provat verktyget. Därmed var den lilla intervjugrupp som deltagit i denna undersökning de första som fick prova på verktyget Wiki då det fortfarande var i

uppstartningsskede på företaget. Jag förstår Mader angående att skapa en test-Wiki, då det är viktigt att veta hur företaget vill bygga upp just sin Wiki eftersom det finns oändliga

möjligheter med tanke på avsaknaden av den klassiska hierarkiska strukturen. Även Ramage (2000) tar upp, se 3.2, att det är viktigt att undersöka huruvida systemet kan anpassas till företaget för att möjliggöra det mest effektiva resultatet vid en implementering. Som beskrivs under stycke 4.4 känner ingen informant att verktyget behöver anpassas mer för företaget. Här menar jag dock att de motsäger sig själva då exempelvis informant 4 trycker på att införandet ska tas i lugn takt just för att finna den uppbyggnaden som passar företaget. Jag menar att genom att utföra implementeringen i lugn takt kan företaget tidigare upptäcka när de är på fel väg istället för att göra det när arbetet har kommit långt och stora resurser lagts ner i onödan. Testgruppen, som jag menar kan hjälpa till att hitta så kallade fel i skarpt läge, anser jag även kan hjälpa till att skapa positiva värden för den stora massan. Vad jag menar är att företaget kan övertyga de övriga anställda genom att övertyga den lilla testgruppen, då de anställda lyssnar på testgruppen eftersom det är de som har provat verktyget mest och upplevs kunna det bäst. De har helt enkelt störst erfarenhet av verktyget på företaget.

En annan aspekt som jag anser vara viktigt vid en implementering av ett nytt

informationsverktyg är om de som ska använda verktyget tror på det. Ramage (2000), se 3.2, menar att man bör undersöka vad människor anser om verktyget innan en implementering av det sker. I stycke 4.4 beskrivs att alla informanter tror på Wiki som verktyg och 90% menar att de kommer att använda det i sitt arbete. Jag anser att om inte den lilla testgruppen tror på verktyget kommer inte resten av de anställda heller att göra det, eftersom testgruppens åsikter anammas av de resterande anställda. Som jag var inne på i tidigare stycke ovan menar jag att det är viktigt att genomföra implementeringen av ett nytt system i lugn takt, om än inte för lugnt. Tvingar du på människor något nytt blir de reserverade och motsträviga, vilket kallas Wikiphobia (Mader, 2008, s.110), se 3.3.3. En Wikiphobia anser jag att bäst tas omhand genom att inte stressa fram verktyget utan genomföra en successiv implementering vilket inte blir en lika dramatisk övergång för användaren.

Under punkt 3.3.3 kan du läsa att Choate (2008, s.17) menar att det största problemet vid ett införande av Wiki är att få människor att delta. Jag menar att människan är en vanemänniska och vi uppskattar inte för stora förändringar, även om de för gott med sig. Vi känner oss trygga med det som vi har, eftersom vi vet hur de nuvarande verktygen och systemen fungerar. Informant 5 menar att Wiki inte kommer att användas om inte övriga verktyg och system som i dagsläget används plockas bort, se 4.4. Jag håller med informanten om att det bästa, precis som diskuterades under punk 5.1, vore om all information var sökbar från en plats. Dock anser jag att verktyget kommer att användas även om andra verktyg släpar kvar. Det gäller att med hjälp av testgruppen och utbildning övertyga övriga användare om möjligheterna med Wiki och på så sätt successivt få dem att börja använda verktyget. Något som både Mader (2008, s.70), se 3.3.3, och informant 7 tar upp, se stycke 4.4, är hänvisningar till Wiki. Detta ser jag som ett smart drag. Genom att hänvisa till verktyget får företaget in användarna i det, som då har möjlighet att upptäcka verktyget och bilda sig en uppfattning. På så sätt blir de inte intvingade utan hänvisade till Wiki; det finns i Wikin, sök

på det här ordet. Jag menar att där är en skillnad mellan att bli intvingad och hänvisad till ett

verktyg. Genom att bli hänvisade och gradvis vägledda till verktyget blir vi omedvetet successivt övertygade och upplever inte den radikala förändringen som det hade blivit om vi en dag skulle bli påtvingade att endast använda det nya verktyget. Därför menar jag att det är positivt om det går trögt i början av implementeringen, vilket beskrivits i stycke 4.4 att två informanter anser att det kommer att göra.

Större delen av informanterna, 70% se 4.4, anser att Wikin var lätt att förstå sig på. Då kan man tänka sig att utbildning inte borde efterfrågas, vilket dock görs. Som jag beskrev i stycke 3.3.3 betonar även Mader (2008, s.60) vikten av utbildning för en framgångsrik Wiki. Jag menar att utbildning är ett krav för att få anställda att börja använda sig av verktyget. Som informant 7 är inne på i stycke 4.4 lockar en kortare utbildning till användning och visar vilka möjligheter som finns med verktyget. Endast utdelande av en handbok där funktioner

beskrivs och regler presenteras anser jag inte skapar denna nyfikenhet och aha-upplevelse som en utbildning kan göra. Dock skulle jag hålla utbildningen något längre än majoriteten av informanterna föreslår, se figur 8 under punkt 4.4. En timmes utbildning menar jag skulle vara lagom. Då finns tid att förklara alla funktioner och även rum för frågor. Behöver användaren senare bli påmind om hur verktyget fungerar eller vilka regler som gäller kan en användarhandbok, där företaget har beskrivit funktioner och vilka regler som gäller för brukandet av Wikin, vara till nytta. Som jag nämner under punkt 3.3.3 menar Choate (2008, s.17) att regler för Wiki är ett krav för att verktyget ska lyckas. Genom att ha klara regler och

förhållningssätt nedskrivna anser jag att företaget skapar en tydlighet mot användarna. Klara direktiv över hur verktyget ska användas menar jag undviker osäkerhet och minimerar risker för att användare utnyttjar verktyget på, enligt företaget, fel sätt.

Mader (2008, s.67-68) nämner, se 3.3.3, att alla anställda bör få en egen Wiki-space. Detta ser jag som en möjlighet till vidare utbildning i verktyget. Användare får chans att prova själv, utan risk att förstöra eller ta bort viktig information, vilket just avskildheten från andra Wiki- spaces möjliggör. På så vis undviks också leka-i-sandlådan-risken som Mader (2008, s.111) tar upp, se punkt 3.3.3. Genom att ha en egen Wiki-space att prova i menar jag att användaren utvecklar sin Wiki-kunskap och kommer på så sätt inte att känna nervositet eller rädsla för att redigera sidor i huvud-Wikin. Dock instämmer jag med Mader (2008, s.112), se stycke 3.3.3, att tomma sidor ändå inte bör finnas. Även om användaren har lärt sig hur sidor ska redigeras i Wiki är det ingen som vill vara först ut, då det känns lättare att lägga till text på sidor som redan är påbörjade.

Ramage (2000) tar upp i sin modell, se 3.2, att ett system bör testas för att se om det fungerar i verkligheten innan implementering. Som beskrivs i stycke 4.3 anser alla informanter att verktyget även fungerar i praktiken och inte endast är teori som låter bra. Att detta är en förutsättning för att över huvud taget kunna utnyttja verktyget instämmer jag till fullo med Ramage. Fungerar det inte i praktiken, utan endast låter bra kommer verktyget inte att användas och de anställda istället återgå till gamla verktyg. Skulle ett verktyg, som senare upptäcks inte fungera i verkligheten, implementeras och övriga tas bort menar jag att detta kan ge företaget oanade konsekvenser. Detta eftersom ett fungerande informationshanterings- verktyg är ett krav för att kunna konkurera på dagens marknad (ne.se, 12-04-2010), se 3.1.