Vad du än säger, så är kunskapshantering (KM) fortfarande ett så konstigt djur bland IT-specialister: Det verkar uppenbart att kunskap är makt (c), men vanligtvis betyder detta någon form av personlig kunskap, egen erfarenhet, genomförda utbildningar, upppumpade färdigheter . Företagsomfattande kunskapshanteringssystem är sällan genomtänkta, trögt, och i grund och botten förstår de inte vilket värde kunskapen hos en viss utvecklare kan tillföra i hela företaget. Det finns undantag förstås. Och samma Alexey Sidorin från CROC gav nyligen en utmärkt . Men dessa är fortfarande isolerade fenomen.
Så på Habré finns det fortfarande ingen hub dedikerad till kunskapshantering, så jag skriver mitt inlägg i konferenshubben. Helt berättigat, om något, för den 26 april, tack vare initiativet från Oleg Bunin-konferenserna, ägde den första konferensen i Ryssland om kunskapshantering inom IT rum - .
Jag hade turen att arbeta i konferensens programkommitté, att se och höra en massa saker som till viss del vände upp och ner på min mysiga värld av kunskapshanteringschef och att förstå att IT redan har mognat till kunskapshantering. Det återstår att förstå vilken sida man ska närma sig det från.
För övrigt hölls ytterligare två konferenser om kunskapshantering den 10 och 17-19 april: и , där jag fick tillfälle att fungera som expert. Dessa konferenser hade ingen IT-bias, men jag har något att jämföra med. I mitt första inlägg vill jag prata om tankarna att deltagandet i dessa konferenser inspirerade mig, en kunskapshanteringsspecialist. Detta kan ses som ett råd till framtida talare, såväl som för dem som arbetar med kunskapshantering per arbetslinje.
Vi hade 83 rapporter, 24 tider och 12 dagar för beslutsfattande
83, Karl. Detta . Trots att detta är den första konferensen, och få personer är inblandade i centraliserad kunskapshantering inom IT, var intresset för ämnet stort. Situationen komplicerades något av det faktum att 13 platser av 24 redan var upptagna vid deadline för att skicka in ansökningar, och talarna trodde nog att med deadline hade allt det roliga bara börjat, så under de senaste dagarna hällde in nästan hälften av ansökningarna till oss. Naturligtvis, 12 dagar före slutförandet av programmet, var det orealistiskt att arbeta bra med alla potentiella talare, därför finns det en möjlighet att några intressanta rapporter utelämnades på grund av ointressanta sammanfattningar. Och ändå tror jag att programmet innehöll starka, djupa och, viktigast av allt, tillämpade rapporter med många detaljer och metoder.
Och ändå skulle jag vilja dra vissa slutsatser av analysen av alla inlämnade ansökningar. Kanske kommer de att vara användbara för några av läsarna och ge en ny förståelse för kunskapshantering. Allt jag kommer att skriva härnäst är ren IMHO, baserat på sex års erfarenhet av att bygga ett kunskapshanteringssystem på Kaspersky Lab och kommunicera med proffs inom datavetenskap.
Vad är kunskap?
På ungdomskonferensen inledde varje talare, vare sig det är en metodolog, en universitetsprofessor eller en talare som är direkt ansvarig för kunskapshanteringen i sitt företag, med frågan "Vad är det för kunskap som vi ska förvalta?"
Jag måste säga att frågan är viktig. Som erfarenheten av att arbeta på PC KnowledgeConf 2019 visade, tror många inom IT-området att kunskap = dokumentation. Därför hör vi ofta frågan: ”Vi dokumenterar koden ändå. Varför behöver vi ytterligare ett kunskapshanteringssystem? Räcker det inte med dokumentation?"
Nej, inte tillräckligt. Av alla de definitioner som talarna gav till kunskap är den som står mig närmast den av Evgeniy Viktorov från Gazpromneft: "kunskap är den erfarenhet som en specifik person har fått av att lösa ett specifikt problem." Observera, ingen dokumentation. Ett dokument är information, data. De kan användas för att lösa ett specifikt problem, men kunskap är erfarenhet av att använda dessa data, och inte själva datan. Som med frimärken: det dyraste frimärket kan du köpa på posten, men det får värde för en samlare först efter att det stämplats med ett frimärke. Du kan försöka avslöja ännu mer: dokumentation = "vad står i koden", och kunskap = "varför det är skrivet precis som det var, hur detta beslut togs, vilket syfte det löser."
Det måste sägas att det till en början inte fanns någon konsensus bland PC-medlemmarna om dokumentation och kunskap. Jag tillskriver detta faktum att PC:n faktiskt inkluderade människor från olika verksamhetsområden, och alla var involverade i kunskapshantering från olika håll. Men vi kom så småningom fram till en gemensam nämnare. Men att förklara för talarna varför deras rapport om att dokumentera kod inte var lämplig för denna konferens var ibland en svår uppgift.
Träning vs. Kunskapshantering
Också en intressant aspekt. Speciellt de senaste dagarna har vi fått en hel del rapporter om träning. Om hur man lär ut mjuka färdigheter, hårda färdigheter, coaching osv. Ja, det är klart, lärande handlar om kunskap. Men vilka? Om vi pratar om extern coaching eller "as is"-utbildning, ingår detta i begreppet företags kunskapshantering? Vi tar extern expertis och tillämpar den där det gör ont. Ja, specifika personer fick nya erfarenheter (=kunskaper), men ingenting hände på en företagsomfattande basis.
Nu, om en anställd efter avslutad utbildning kom till kontoret och genomförde en liknande mästarklass för kollegor (rotade runt efter kunskap) eller överförde sina intryck och nyckelidéer som han hade samlat på sig till någon form av villkorad intern kunskapsbas - detta är kunskapshantering. Men de brukar inte tänka på (eller prata om) denna koppling.
Om vi tar personlig erfarenhet är det vanligt på vår avdelning att efter konferensen beskriva intryck, keynotes, idéer, lista rekommenderade böcker etc. i en särskild del av den interna portalen. Så är fallet när det inte finns någon motsättning mellan begrepp. Kunskapshantering är i detta fall en naturlig förlängning av externt lärande.
Om nu kollegorna som lämnade in rapporter om coaching skulle prata om till exempel hur de delar med sig av praktiker i deras coachingcommunity och vilka frukter det ger, skulle det verkligen handla om CM.
Eller låt oss ta det från andra sidan. Det fanns också rapporter om hur företaget skapat en kunskapsbas. Punkt. Färdig tanke.
Men varför skapade de det? Ska den insamlade kunskapen fungera? Utanför IT-gemenskapen, som fortfarande är mer tillämpad och praktisk, stöter jag ofta på berättelsen om att utförare av ett kunskapshanteringsprojekt tror att det räcker med att köpa mjukvara, fylla den med material, och alla kommer att gå och använda den själva om nödvändig. Och då blir de förvånade över att på något sätt KM:n inte tar fart. Och det fanns sådana talare också.
Enligt min åsikt samlar vi på oss kunskap så att någon utifrån dess grund kan lära sig något och inte göra några misstag. Intern utbildning är en naturlig förlängning av ett kunskapshanteringssystem. Ta onboarding eller mentorskap i team: trots allt delar mentorer intern information så att medarbetaren snabbt går med i teamet och processerna. Och om vi har en intern kunskapsbas, var finns all denna information? Är inte detta en anledning att avlasta mentorns arbetsbörda och påskynda onboarding? Dessutom kommer kunskap att finnas tillgänglig 24/7, och inte när teamledaren har tid. Och om företaget kommer på denna idé kan motsättningen mellan villkoren också tas bort.
I min praktik är det precis det jag gör: Jag samlar på mig kunskap och sedan skapar jag, utifrån det insamlade materialet, utbildningar av varierande detaljnivå för kollegor från olika avdelningar. Och om du lägger till ytterligare en modul till kunskapshanteringssystemet för att skapa tester för att övervaka medvetenhet och färdigheter hos anställda, får du i allmänhet en idealisk bild av samma företags kunskapsdelning: vissa delade informationen, andra bearbetade den, paketerade den och delade det för målgrupper, och sedan kontrollerade vi assimileringen av materialen.
Marknadsföring vs. Öva
Ögonblicket är också intressant. Ofta, om kunskapshantering utförs av en utsedd medarbetare (HR, L&D), så är hans stora uppgift att sälja in KM-idén till företagets anställda och skapa värde. Alla måste sälja en idé. Men om kunskapshantering utförs av en person som löser sin personliga smärta med detta verktyg och inte utför en ledningsuppgift, så behåller han vanligtvis fokus på de tillämpade aspekterna av projektet. Och en personalutvecklingsanställd upplever ofta en viss professionell deformation: han ser hur man säljer det, men förstår inte riktigt varför det är uppbyggt så. Och en rapport lämnas till konferensen, som är ett halvtimmes rent marknadsföringstal om vilka godsaker systemet tillför, och inte innehåller ett ord om hur det fungerar. Men detta är just det mest intressanta och viktigaste! Hur är det ordnat? Varför är det så? Vilka inkarnationer upplevde hon, och vad passade inte henne i tidigare implementeringar?
Om du skapar ett vackert omslag för en produkt kan du förse användare med det under en kort stund. Men intresset försvinner snabbt. Om den som genomför ett kunskapshanteringsprojekt inte förstår dess "kött", tänker i siffror och mått och inte i målgruppens verkliga problem, kommer nedgången att komma väldigt snabbt.
När du kommer till en konferens med en sådan rapport, som ser ut som en reklambroschyr, måste du förstå att det inte kommer att vara intressant "utanför" ditt företag. De som kom för att lyssna på dig har redan köpt idén (de betalade faktiskt mycket pengar för att delta!). De behöver inte vara övertygade om att det i princip är nödvändigt att ägna sig åt CT. De måste få veta hur de ska göra det och hur de inte ska göra det, och varför. Det här är inte din högsta ledning, din bonus beror inte på publiken i hallen.
Och ändå är dessa också två delar av ett projekt, och utan bra marknadsföring inom företaget kommer även det coolaste innehållet att förbli ytterligare en Sharepoint. Och om du berättar för mig как du säljer idén om KM till dina kollegor, vilka funktioner som fungerar och vilka som inte gör det, och varför, då kommer historien att vara väldigt, väldigt värdefull.
Men den andra ytterligheten är också möjlig: vi skapade den coolaste basen, använde så avancerade metoder, men av någon anledning gick inte de anställda dit. Därför blev vi besvikna på idén och slutade göra det. Vi hade också sådana önskemål. Varför stöttade inte de anställda? Kanske behövde de verkligen inte denna information (detta är ett problem med att studera målgruppen, ett separat inlägg bör skrivas om det). Eller kanske de helt enkelt var dåligt kommunicerade? Hur gjorde de ens det? En kunskapshanteringschef är också en bra PR-specialist. Och om han vet hur man upprätthåller en balans mellan marknadsföring och användbarhet av innehåll, då har han en stor chans att lyckas. Man kan inte prata om det ena samtidigt som man glömmer det andra.
siffror
Och slutligen, om siffrorna. Jag läste i en talares memo på en av konferenserna (inte KnowledgeConf!) att publiken älskar exklusiv information – siffror. Men varför? Inför den konferensen funderade jag länge på hur mina siffror skulle kunna vara användbara för publiken? Hur kommer det att hjälpa mina kollegor att jag lyckades förbättra någon indikator på anställdas produktivitet med N% genom kunskapshantering? Vad kommer mina lyssnare att göra annorlunda imorgon om de känner till mina siffror? Jag kom med bara ett argument: "Jag gillade en av dina metoder, jag vill implementera den själv, men jag måste sälja idén till chefen. I morgon ska jag berätta för honom att det i företag X ledde till en sådan ökning av indikatorer att han "köpte" den här idén.". Men alla mina resultatindikatorer är inte tillämpliga på någon annan verksamhet. Du kanske kan ge några andra argument till förmån för siffrorna i rapporterna? Men enligt min mening är det ingen bra idé att spendera 10 minuter av en 30-minutersrapport på siffror när du kan lägga dem på praktiska exempel eller till och med en liten workshop med en publik, IMHO.
Och vi fick också rapporter fulla av siffror. Efter den första diskussionen bad vi talarna att prata om de metoder som ledde till sådana resultat. De av dem som så småningom tog sig till det slutliga programmet hade rapporter som skilde sig nästan helt från originalversionen. Som ett resultat har vi redan hört mycket feedback om den enorma praktiska grund som konferensen gav. Och ingen har ännu sagt att "det var intressant att ta reda på hur mycket företag X sparade genom kunskapshantering."
Avslutningsvis på denna långa läsning vill jag återigen glädja mig åt att IT-världen har insett vikten av kunskapshantering och, jag hoppas, kommer att börja aktivt implementera, optimera och anpassa den inom en snar framtid. Och på Habré kommer det att finnas ett separat nav dedikerat till kunskapshantering, och alla våra talare kommer att dela kunskap med kollegor där. Under tiden kan du utforska praxis i instant messengers, Facebook och andra tillgängliga kommunikationsmedel. Vi önskar er alla bara användbara rapporter och framgångsrika tal!
Källa: will.com