Hej alla. Efter Ett halvår har gått och under den tiden hann jag tala på ytterligare två konferenser och hålla föredrag på ämnet kunskapshantering i två stora IT-företag. När jag kommunicerade med kollegor insåg jag att inom IT är det fortfarande möjligt att prata om kunskapshantering på "nybörjarnivå", eller snarare, bara för att inse att kunskapshantering behövs av vilken avdelning som helst på vilket företag som helst. Idag kommer det att finnas ett minimum av min egen erfarenhet - jag skulle vilja överväga befintliga internationella standarder inom området kunskapshantering.
Låt oss börja med det förmodligen mest populära varumärket inom standardiseringsområdet - ISO. Föreställ dig, det finns en hel separat standard dedikerad till kunskapshanteringssystem (ISO 30401:2018). Men idag skulle jag inte ägna mig åt det. Innan du förstår "hur" ett kunskapshanteringssystem ska se ut och fungera måste du vara överens om att det i princip behövs.
Låt oss ta till exempel ISO 9001: 2015 (Kvalitetsledningssystem). Som namnet antyder är detta en standard dedikerad till kvalitetsledningssystem. För att bli certifierad enligt denna standard måste en organisation säkerställa att dess affärsprocesser och produkter och/eller tjänster är transparenta och sömlösa. Certifikatet innebär med andra ord att allt i ditt företag fungerar tydligt och smidigt, du förstår vilka risker den nuvarande organisationen av processer innebär, du vet hur du kontrollerar dessa risker och du strävar efter att minimera dem.
Vad har kunskapshantering med det att göra? Här är vad det har med det att göra:
7.1.6 Organisationskunskap
Organisationen ska fastställa den kunskap som krävs för att driva sina processer och uppnå överensstämmelse mellan produkter och tjänster.
Kunskapen ska upprätthållas och göras tillgänglig i den utsträckning som krävs.
När organisationen överväger förändrade behov och trender måste organisationen ta hänsyn till sin befintliga kunskap och bestämma hur man skaffar eller ger tillgång till ytterligare kunskap och uppdaterar den.
ANM. 1: Organisationskunskap är kunskap specifik för en organisation; mestadels härledd från erfarenhet.
Kunskap är information som används och utbyts för att uppnå organisatoriska mål.
NOT 2 En organisations kunskapsbas kan vara:
a) interna källor (t.ex. immateriella rättigheter; kunskap som erhållits genom erfarenhet; lärdomar från misslyckade eller framgångsrika projekt; insamling och utbyte av odokumenterad kunskap och erfarenhet; resultat av process-, produkt- och tjänsteförbättringar);
b) externa källor (t.ex. standarder, akademi, konferenser, kunskap från kunder och externa leverantörer).
Och nedan, i bilagorna:
Organisatoriska kunskapskrav har införts för:
a) skydda organisationen från förlust av kunskap, till exempel på grund av:
- personalomsättning;
- oförmåga att erhålla och utbyta information;
b) uppmuntra organisationen att skaffa kunskap, till exempel genom:
- lärande genom att göra;
- mentorskap;
- benchmarking.
Så ISO-standarden inom området kvalitetsledning säger att för att säkerställa kvaliteten på sin verksamhet måste ett företag engagera sig i kunskapshantering. Det stämmer, det finns inget alternativ - "måste". Annars avvikelse, och adjö. Enbart detta faktum verkar antyda att detta inte är en frivillig aspekt i organisationen, eftersom kunskapshantering inom IT ofta behandlas, utan en obligatorisk komponent i affärsprocesser.
Dessutom beskriver standarden vilka risker kunskapshantering är utformad för att eliminera. Faktum är att de är ganska uppenbara.
Låt oss föreställa oss... nej, inte så - kom ihåg en situation från din karriär när du verkligen behövde lite information för jobbet, och dess enda transportör var vid det ögonblicket på semester/affärsresa, slutade helt på företaget eller var helt enkelt sjuk . Kommer du ihåg? Jag tror att nästan alla av oss har fått ta itu med det här. Hur kände du i det ögonblicket?
Om avdelningsledningen efter en tid undersöker misslyckandet med att uppfylla projektdeadlines, kommer de naturligtvis att hitta någon att skylla på och lugna ner sig på det. Men för dig personligen, i det ögonblick då du behövde kunskap, förståelsen att "RM är skyldig, som åkte till Bali och inte lämnade några instruktioner i händelse av frågor." Självklart är han skyldig. Men detta hjälper inte att lösa ditt problem.
Om kunskap dokumenteras i ett system som är tillgängligt för människor som kan behöva det, blir den beskrivna "resort"-historien nästan omöjlig. Därmed säkerställs kontinuiteten i affärsprocesserna, vilket innebär att semester, anställdas avgångar och den ökända bussfaktorn inte är ett hot mot företaget - kvaliteten på produkten/tjänsten kommer att förbli på sin vanliga nivå.
Om företaget har en plattform för att utbyta och lagra information och erfarenheter, och även har bildat en kultur (vana) att använda denna plattform, behöver anställda inte vänta flera dagar på svar från en kollega (eller ens söka i flera dagar) för den här kollegan) och vänta på dina uppgifter.
Varför pratar jag om vana? För det räcker inte att skapa en kunskapsbas för att folk ska börja använda den. Vi är alla vana vid att söka svar på våra frågor på Google och oftast kopplar vi intranätet till semesteransökningar och anslagstavlor. Vi har inte för vana att "söka information om Agila ramverk" (till exempel) på intranätet. Därför, även om vi har den coolaste kunskapsbasen på en sekund, kommer ingen att börja använda den nästa sekund (eller ens nästa månad) - det finns ingen vana. Att ändra dina vanor är smärtsamt och tidskrävande. Alla är inte redo för detta. Särskilt om de "arbetat på samma sätt" i 15 år. Men utan detta kommer företagets kunskapssatsning att misslyckas. Det är därför KM-experter oupplösligt kopplar samman kunskapshantering med förändringsledning.
Det är också värt att uppmärksamma det faktum att "När man överväger förändrade behov och trender måste en organisation ta hänsyn till sin befintliga kunskap ...", dvs. utveckla en kultur där man hänvisar till tidigare erfarenheter när man fattar beslut i en föränderlig värld. Och märk igen "måste".
Förresten, det här lilla stycket i standarden säger mycket om erfarenhet. Vanligtvis, när det kommer till kunskapshantering, börjar stereotyper antyda en bild av en kunskapsbas med hundratals dokument placerade i form av filer (föreskrifter, krav). Men ISO talar om erfarenhet. Kunskaper från tidigare erfarenheter av företaget och var och en av dess anställda är det som gör att du kan undvika risken för att upprepa misstag, omedelbart fatta mer lönsamma beslut och till och med skapa en ny produkt. I de mest mogna företagen inom kunskapshanteringsområdet (inklusive ryska, förresten) betraktas kunskapshantering som ett sätt att öka företagets kapitalisering, skapa nya produkter, utveckla nya idéer och optimera processer. Detta är inte en kunskapsbas, det är en mekanism för innovation. Hjälper oss att förstå detta mer i detalj PMI:s PMBOK-guide.
PMB OK är en guide till kunskapsmassan om projektledning, en PM-handbok. Den sjätte upplagan (2016) av denna guide introducerade ett avsnitt om projektintegrationshantering, som i sin tur innehåller ett underavsnitt om projektkunskapshantering. Denna paragraf skapades "baserat på kommentarer från användare av manualen", dvs. blev en produkt av erfarenhet av att använda tidigare versioner av guiden under verkliga förhållanden. Och verkligheten krävde kunskapshantering!
Huvudutgången för det nya objektet är "Register of Lessons Learned" (i ISO-standarden som beskrivs ovan nämns den förresten också). Dessutom, enligt ledningen, bör sammanställningen av detta register utföras under hela genomförandet av projektet, och inte vid dess slut, när det är dags att analysera resultatet. Enligt mig är detta väldigt likt retrospektiv inom agilt, men jag kommer att skriva ett separat inlägg om detta. Den ordagranta texten i PMBOK lyder så här:
Projektkunskapshantering är processen att använda befintlig kunskap och skapa ny kunskap för att uppnå projektmål och främja lärande i organisationen
Kunskapsområdet för projektintegrationshantering kräver integrering av resultat från alla andra kunskapsområden.
Nya trender i integrationsprocesser inkluderar, men är inte begränsade till:
.
• Projektkunskapshantering
Arbetskraftens allt mer rörliga och föränderliga karaktär kräver också en mer rigorös process för att definiera kunskap under hela projektets livscykel och överföra den till målgrupper så att kunskap inte går förlorad.
***
De viktigaste fördelarna med denna process är att organisationens tidigare inhämtade kunskaper används för att erhålla eller förbättra projektresultat, och kunskap från det pågående projektet förblir tillgänglig för att stödja organisationens verksamhet och framtida projekt eller faser av dessa. Denna process fortsätter under hela projektet.
Jag kommer inte att kopiera och klistra in hela den stora delen av manualen här. Du kan bekanta dig med det och dra lämpliga slutsatser. De ovan presenterade citaten är enligt min mening helt tillräckliga. Det förefaller mig som att förekomsten av sådana detaljer i PM:s uppgift att hantera projektkunskap redan indikerar vikten av denna aspekt när man arbetar med projekt. Förresten, jag hör ofta tesen: "Vem behöver vår kunskap på andra avdelningar?" Jag menar, vem behöver dessa lärdomar?
Faktum är att det ofta ses att en enhet ser sig själv som en "enhet i ett vakuum." Här är vi med vårt bibliotek, men där finns resten av företaget, och kunskap om vårt bibliotek är henne till ingen nytta. Om biblioteket - kanske. Hur är det med de medföljande processerna?
Ett trivialt exempel: under arbetet med projektet förekom interaktion med entreprenören. Till exempel med en designer. Entreprenören visade sig vara sisådär, missade deadlines och vägrade slutföra arbetet utan ytterligare betalning. RM registrerade i registret för lärdomar att det inte var värt att arbeta med denna opålitliga entreprenör. Samtidigt letade man någonstans i marknadsföringen också efter en designer och stötte på samma entreprenör. Och för närvarande finns det två alternativ:
a) om företaget har en väletablerad kultur för att återanvända erfarenhet, kommer en kollega från marknadsföring att titta i registret över lärdomar för att se om någon redan har kontaktat denna entreprenör, kommer att se negativ feedback från vår PM och inte slösa tid och pengar som kommunicerar med denna opålitliga entreprenör.
b) om företaget inte har en sådan kultur kommer marknadsföraren att vända sig till samma opålitliga entreprenör, förlora företagets pengar, tid och kan till exempel störa en viktig och brådskande reklamkampanj.
Vilket alternativ verkar vara mer framgångsrikt? Och observera att det inte var informationen om produkten som utvecklades som var användbar, utan om processerna som följer med utvecklingen. Och det visade sig vara användbart inte för en annan RM, utan för en anställd i en helt annan riktning. Därav slutsatsen: utveckling kan inte ses separat från försäljning, teknisk support från affärsanalys och IT från administrativ ledning. Alla i företaget har arbetslivserfarenhet som kommer att vara till nytta för någon annan i företaget. Och dessa kommer inte nödvändigtvis att vara representanter för relaterade områden.
Den tekniska sidan av projektet kan dock också vara användbar. Försök att granska projekt i ditt företag under de senaste åren. Du kommer att bli förvånad över hur många cyklar som har uppfunnits för att lösa liknande problem. Varför? Eftersom kunskapsdelningsprocesser inte har etablerats.
Så kunskapshantering, enligt PMI-manualen, är en av PM:s uppgifter. Som vi kan se inkluderar två välkända organisationer som genomför betalda certifieringar enligt sina standarder kunskapshantering i sina listor över måste-ha verktyg för kvalitetskontroll och projektarbete. Varför tror chefer i IT-företag fortfarande att kunskapshantering är dokumentation? Varför förblir kylaren och rökrummet centrum för kunskapsutbyte? Allt är en fråga om förståelse och vanor. Jag hoppas att IT-chefer successivt blir mer medvetna om området kunskapshantering och muntlig tradition inte längre kommer att fungera som ett verktyg för att bevara kunskap i företaget. Studera dina arbetsnormer - det finns mycket intressant i dem!
Källa: will.com