Hur man implementerar Kunskapsbas 2.0 i Harmony: Historien om Easy Software

Vad är Knowledge Base 2.0

Det är det perfekta sättet att få tillgång till ett företags kunskap, integrerat i Easy Redmine och ger en kraftfull verktygssats för att organisera och skala dokumentation, manualer, processer, kvalitetsstyrning och andra behov för att upprätthålla kunskap inom en organisation.

Läs mer

Hur vi skapade det

• Vad var utmaningen: På Easy Software blev mängden intern kunskap att dela för komplex för den tidigare lösningen. Bara en vanlig uppsättning artiklar i kategorier räckte inte längre.
• Vad vi behövde: Vi letade efter en specialiserad applikation, så nära kopplad till Easy Redmine som möjligt. Den måste definitivt vara öppen källkod eftersom vi stöder det och Easy Redmine självt är öppen källkod.
• Vilken lösning vi valde: BlueSpice passar definitionen perfekt. Det är en öppen källkodslösning, ett specialiserat wikiverktyg, med komplex anpassningsbarhet och integration med Easy Redmine.

Hur migreringen ägde rum

Vi hade redan befintliga data i vår tidigare kunskapsdatabas. Vi ville överföra mycket av det till den nya lösningen. Se vilka sju steg vi har tagit:

1. Rensa upp data i den ursprungliga kunskapsdatabasen – börja innan migreringen. Vi rekommenderar att sortera alla artiklar efter "senast uppdaterad" datum och gå från äldst till nyast.

• Du kommer att märka att många artiklar från toppen kan helt enkelt raderas
• Andra kan du placera i en specifik kategori som kallas "för granskning" – du kommer att uppdatera dem senare
• Vissa kan uppdateras omedelbart
• Resten kan vara oförändrade

Två fler tips:

• Om fler personer ska granska artiklarna, kan det vara en bra idé att på något sätt märka dem eller ange ett anpassat fält – till exempel "Granskad".
• Kontrollera också titlarna på artiklarna. Om de innehåller problematiska symboler kan de orsaka problem under migreringen. Här är några tips på mediawiki.org om sidtitlar och Legal Title Chars.

Läs mer

2. Installera Kunskapsdatabas 2.0 – teknisk leverans av funktionen. Eftersom vi kör på Easy Cloud, gjordes det nästan automatiskt

3. Gör några testmigreringar – vi var osäkra på resultatet, så vi gjorde en testmigrering

• Vi kontrollerade sidtitlar, innehållsformatering (rubriker, stycken, länkar och bilder) och kategorier
• Vi kontrollerade hur lång tid det skulle ta (vi hade över 900 artiklar att migrera)
• Vi gjorde nödvändiga ändringar i innehållet i den ursprungliga kunskapsdatabasen baserat på våra resultat från testmigreringen
• Vi "uppdaterade" Kunskapsdatabas 2.0-applikationen – tog bort all data

4. Information till våra användare

• Vi informerade dem om produktionsmigreringens datum = efter denna tidpunkt är primär kunskapskälla Kunskapsdatabas 2.0. Efter denna tidpunkt kommer användare endast ha läsåtkomst till de ursprungliga artiklarna (bara för referens och jämförelse) hur de ser ut nu och tidigare
• Vi höll några omgångar av användarutbildning och administratörsutbildning

5. Produktionsimport

• Dagen kom när vi skulle klicka på knappen och migreringen kördes
• Efter vår initiala kontroll sänkte vi behörigheterna för alla roller i den ursprungliga kunskapsdatabasen – till läsläge

Se migreringsprocessen

6. Intern support

• Vi utsåg några kollegor och en kanal i Microsoft Teams där våra användare kunde ställa frågor om funktionen i Kunskapsdatabas 2.0
• Några problem efter migreringen har upptäckts i produktionen. Eftersom vi fortfarande hade den ursprungliga aktiva, kunde vi lösa varje problem på rätt sätt

7. Inaktivera den ursprungliga kunskapsdatabasen

• Efter cirka 6 veckor avtog supportförfrågningarna
• Vi inaktiverade den ursprungliga kunskapsdatabasen från vår Easy Redmine-applikation
• Vi rekommenderar att göra en säkerhetskopia innan du avinstallerar tillägget

Hur företaget accepterade en förändring

Varje förändring i en organisation tar tid att bli fullständigt accepterad. Början är svårast, vilket är varför vi måste fortsätta påminna våra användare om fördelarna med det nya systemet.

I fallet med Knowledge Base 2.0 är det uppenbara att om du inte vet något, försök att först söka (glödlampa i sidofältet). Du kommer att se resultat inte bara i form av artikelns titel (som i den ursprungliga Knowledge Base), utan också i själva innehållet på sidorna vid första anblicken => det finns en god chans att du får ett svar utan att behöva gå någon annanstans.

När användaren enkelt och snabbt hittar önskad kunskap från andra är de mer benägna att dela sin kunskap med de andra, som en återgäldning och känsla.

Hur implementeringen fortskred

Kategorier

De importerades från den ursprungliga Knowledge Base, vilket är bra. Men strukturen (kategorier och underkategorier) kunde inte tekniskt importeras. Det första vi gjorde var att granska kategorierna, i vilka sidorna är organiserade.

Vi började med 3 huvudsakliga "dimensioner" av kategorier:

• Publik - för vem sidan är mest användbar - flera alternativ är tillåtna som
• Försäljning
• Utveckling
• Marknadsföring
• Alla
• Dokumenttyp - vilken typ av kunskap som delas. Till slut kommer varje typ att ha sin egen mall, så att de alla ser standardiserade ut. Bästa praxis säger att varje sida bara ska ha en dokumenttyp.
• Policys
• Hur man gör
• Processer
• Träningsanteckningar och inspelningar
• Ämne - vad sidan handlar om. Denna struktur kan gå djupare, eftersom det finns många ämnen i företaget. Att lägga till en sida i en ämneskategori är frivilligt - inte nödvändigt om det inte finns någon lämplig kategori.
• Produkt
• Kärnfunktioner
• Resurshantering
• Hjälpdesk
• Agil tavla
• Infrastruktur
• Moln
• Server
• Hybridlösning
• Intern IT
• Team
• Outlook
• Hårdvara
• Delad hårdvara
• Individuell hårdvara

Eftersom varje redaktör kan skapa nya kategorier gör vi månatliga översyner så att det inte skapas för många otydliga eller engångsanvända kategorier, en slags strukturtidning så att det inte blir kaotiskt.

Navigeringssidor

Det är kritiskt att användarna kan navigera den nya applikationen väl. En naturlig del för navigering är huvudmenyn, som delvis kan anpassas. Ett användbart tillägg är startsidan, som välkomnar läsarna, länkar till artikeln om bästa praxis för Knowledge Base 2.0 och länkar till sidor som är dedikerade till avdelningar i vårt företag.

Genom att klicka på t.ex. Marknadsföring kommer användaren att dirigeras till indexet för marknadsföringssidor för att bläddra igenom. Det innehåller också ytterligare information som är relevant endast för den avdelningen.

Vi överväger att använda navigeringssidor för andra sorteringskriterier (som produktinformation eller allmänna företagspolicys).

Ett steg i taget

När du har ställt in dina kategorier och dina navigeringssidor kan användarna redan arbeta i det. Det kan verka lite rörigt från början, vilket är varför vi har några utvalda administratörer som ser till att det finns ordning.

Vi har använt Knowledge Base 2.0 i några månader nu, och vi är fortfarande bara i början. Vi inser att vi är långt ifrån en idealiskt organiserad och standardiserad wiki som alla användare (oavsett erfarenhet) kan utantill.

Vi tror att det är bättre att gradvis växa kunskapsbasen, organiskt, genom engagerade användare, än att spendera månader på att förbereda ett system som våra användare skulle behöva studera hårt för att förstå.

Vår rekommendation är att noga observera hur användarna använder det och ta små steg mot att implementera mer precisa organisatoriska konfigurationer, som sidmallar, typografiregler, etc. Varje steg som även lite komplicerar användningen av kunskapsbasen för organisationens bästa bör åtföljas av en förklaring om hur det gynnar alla berörda.

Slutsats

Vi på Easy Software har avslutat migrations- och implementeringsprocessen och nu är det din tur. Genom att följa dessa tips ovan och ta inspiration kan vilket företag som helst implementera en ny Knowledge Base 2.0 som uppfyller deras unika behov och håller deras kunskap säker.

Prova det gratis