Mida iganes sa ütled, teadmusjuhtimine (KM) jääb IT-spetsialistide seas ikka nii imelikuks loomaks: Tundub selge, et teadmised on jõud (c), kuid tavaliselt tähendab see mingit isiklikku teadmist, oma kogemust, läbitud koolitusi, ülespumbatud oskusi. . Kogu ettevõtte teadmusjuhtimise süsteemidele mõeldakse harva, loiult ja põhimõtteliselt ei mõisteta, millist väärtust võivad konkreetse arendaja teadmised kogu ettevõttes tuua. Erandeid on muidugi ka. Ja seesama Alexey Sidorin CROCist andis hiljuti suurepärase . Kuid need on ikkagi üksikud nähtused.
Nii et Habres pole ikka veel teadmusjuhtimisele pühendatud keskust, seega kirjutan oma postitust konverentsikeskusesse. Täiesti õigustatult, kui üldse, sest 26. aprillil toimus tänu Oleg Bunini konverentside initsiatiivile Venemaal esimene IT teadmusjuhtimise konverents - .
Mul oli õnn töötada konverentsi programmikomitees, näha ja kuulda palju sellist, mis mu õdusa teadmusjuhtimise juhi maailma mingil määral pea peale pööras, ning mõista, et IT on teadmusjuhtimiseks juba küpsenud. Jääb üle aru saada, kummalt poolt sellele läheneda.
Muide, 10. ja 17.-19. aprillil toimus veel kaks teadmusjuhtimise konverentsi: и , kus mul oli võimalus tegutseda eksperdina. Nendel konverentsidel ei olnud IT-kallutatust, kuid mul on, millega võrrelda. Oma esimeses postituses tahan rääkida mõtetest, mis mind, teadmusjuhtimise spetsialisti, nendel konverentsidel osalemist inspireerisid. Seda võib pidada nõuandeks nii tulevastele esinejatele kui ka neile, kes on seotud teadmusjuhtimisega töövaldkondade kaupa.
Meil oli 83 aruannet, 24 ajavahemikku ja 12 päeva otsuste tegemiseks
83, Karl. See . Vaatamata sellele, et tegemist on esmakordse konverentsiga ja IT tsentraliseeritud teadmusjuhtimisega tegeleb vähe inimesi, oli huvi teema vastu suur. Mõnevõrra muutis olukorra keerulisemaks asjaolu, et avalduste esitamise tähtajaks oli 13-st juba 24 pesa hõivatud ning ilmselt uskusid esinejad, et tähtajaga on kogu melu alles algamas, nii et paaril viimasel päeval olid nad valas meile ligi pooled taotlustest. Muidugi oli 12 päeva enne programmi valmimist ebareaalne iga potentsiaalse esinejaga hästi koostööd teha, mistõttu on võimalus, et mõni huvitav reportaaž jäi ebahuvitavate abstraktide tõttu välja. Ja siiski, ma usun, et programm sisaldas tugevaid, põhjalikke ja, mis kõige tähtsam, rakenduslikke aruandeid, milles oli palju detaile ja tavasid.
Ja ometi tahaksin kõikide esitatud taotluste analüüsi põhjal teha teatud järeldused. Võib-olla on need mõnele lugejale kasulikud ja annavad teadmusjuhtimisest uue arusaama. Kõik, mida ma järgmisena kirjutan, on puhas IMHO, mis põhineb kuueaastasel Kaspersky Labi teadmushaldussüsteemi loomisel ja arvutiteaduse valdkonna professionaalidega suhtlemisel.
Mis on teadmine?
Noortekonverentsil alustas iga esineja, olgu selleks metoodik, ülikooli õppejõud või oma ettevõttes teadmusjuhtimise eest otseselt vastutav esineja, küsimusega “Mis on teadmine, mida me haldama hakkame?”
Pean ütlema, et küsimus on oluline. Nagu näitas PC KnowledgeConf 2019 töökogemus, usuvad paljud IT-valdkonnas, et teadmised = dokumentatsioon. Seetõttu kuuleme sageli küsimust: “Koodi dokumenteerime niikuinii. Miks me vajame teist teadmusjuhtimissüsteemi? Kas dokumentidest ei piisa?”
Ei, ei piisa. Kõigist definitsioonidest, mille esinejad andsid teadmistele, on mulle kõige lähedasem Jevgeni Viktorovi Gazpromneftist: "teadmised on konkreetse inimese kogemused konkreetse probleemi lahendamisel." Pange tähele, dokumente pole. Dokument on teave, andmed. Neid saab kasutada konkreetse probleemi lahendamiseks, kuid teadmised on nende andmete kasutamise kogemus, mitte andmed ise. Nagu ka postmarkidega: postkontorist saab osta kalleima margi, kuid kollektsionääri jaoks omandab see väärtuse alles pärast postmargiga tembeldamist. Võite proovida paljastada veelgi rohkem: dokumentatsioon = "mis on koodis kirjas" ja teadmised = "miks on kirjutatud täpselt nii, nagu see oli, kuidas see otsus tehti, mis eesmärki see lahendab."
Peab ütlema, et algselt ei olnud PC liikmete seas dokumentatsiooni ja teadmiste osas üksmeelt. Pean selle asjaolu põhjuseks, et arvutisse kuulus tegelikult inimesi erinevatelt tegevusaladelt ja kõik olid teadmusjuhtimisega seotud erinevatest külgedest. Kuid lõpuks jõudsime ühise nimetajani. Kuid seletada esinejatele, miks nende aruanne koodi dokumenteerimise kohta selle konverentsi jaoks ei sobinud, oli kohati keeruline ülesanne.
Treening vs. Teadmusjuhtimine
Samuti huvitav aspekt. Eriti viimastel päevadel oleme saanud palju teateid treeningute kohta. Sellest, kuidas õpetada pehmeid oskusi, kõvasid oskusi, juhendamist jne. Jah, loomulikult on õppimine seotud teadmistega. Aga milliseid? Kui me räägime välisest coachingust või “nagu on” koolitusest, siis kas see sisaldub ettevõtte teadmusjuhtimise kontseptsioonis? Me kasutame välist ekspertiisi ja rakendame seda seal, kus see valutab. Jah, konkreetsed inimesed said uusi kogemusi (=teadmisi), aga ettevõtteüleselt ei toimunud midagi.
Nüüd, kui töötaja tuli pärast koolituse läbimist kontorisse ja viis kolleegidele läbi sarnase meistriklassi (teadmiste saamiseks ringi tuhisenud) või kandis oma muljed ja peamised ideed, mille ta oli kogunud, mingisse tingimuslikku sisemise teadmiste baasi - see on teadmiste juhtimine. Kuid tavaliselt nad ei mõtle (ega räägi) sellele seosele.
Kui võtame isikliku kogemuse, siis on meie osakonnas tavaks pärast konverentsi muljeid, põhisõnu, ideid, loetleda soovitatud raamatud jms siseportaali spetsiaalses rubriigis. Seda juhul, kui mõistete vahel puudub vastandus. Teadmusjuhtimine on antud juhul välise õppimise loomulik jätk.
Kui nüüd coachingu kohta raporteid esitanud kolleegid räägiksid näiteks sellest, kuidas nad oma coachingu kogukonnas praktikaid jagavad ja milliseid vilju see toob, siis kindlasti räägiks see CM-ist.
Või võtame asja teisest küljest. Samuti oli aruandeid selle kohta, kuidas ettevõte lõi teadmistebaasi. Punkt. Lõpetatud mõte.
Aga miks nad selle lõid? Kogutud teadmised peaksid toimima? Väljaspool IT-kogukonda, mis on ikka rakenduslikum ja praktilisem, puutun sageli kokku jutuga, et teadmusjuhtimise projekti teostajad usuvad, et piisab tarkvara ostmisest, materjalidega täitmisest ja igaüks läheb ise kasutama, kui vajalik. Ja siis imestatakse, et KM kuidagi õhku ei tõuse. Ja selliseid kõlareid oli ka.
Minu arvates kogume teadmisi selleks, et nende põhjal saaks keegi midagi õppida ega teeks vigu. Sisekoolitus on teadmusjuhtimise süsteemi loomulik jätk. Võtke onboarding või mentorlus meeskondades: mentorid jagavad ju sisemist teavet, et töötaja kiiresti meeskonnaga liituks ja protsessidega liituks. Ja kui meil on sisemine teadmistebaas, siis kus kogu see teave asub? Kas see pole põhjus mentori töökoormuse leevendamiseks ja liitumise kiirendamiseks? Pealegi on teadmised kättesaadavad 24/7, mitte siis, kui meeskonna juhil on aega. Ja kui ettevõte selle ideeni jõuab, saab ka terminite vastanduse eemaldada.
Oma praktikas ma just seda teen: kogun teadmisi ja seejärel koostan kogutud materjalide põhjal erineva detailsusega koolitusi erinevate osakondade kolleegidele. Ja kui lisada teadmushaldussüsteemi veel üks moodul töötajate teadlikkuse ja oskuste jälgimiseks mõeldud testide loomiseks, siis üldiselt saab sellest samast ettevõtte teadmiste jagamisest ideaalse pildi: ühed jagasid infot, teised töötlesid, pakkisid ja jagasime seda sihtrühmadele ja Seejärel kontrollisime materjalide assimilatsiooni.
Turundus vs. Harjuta
Hetk on ka huvitav. Tihtipeale, kui teadmusjuhtimisega tegeleb selleks määratud töötaja (HR, L&D), siis tema suureks ülesandeks on KM-idee ettevõtte töötajatele müümine ja väärtuse loomine. Igaüks peab oma idee maha müüma. Kui aga teadmusjuhtimisega tegeleb inimene, kes lahendab selle tööriistaga oma isikliku valu, mitte ei täida juhtimisülesannet, siis keskendub ta tavaliselt projekti rakenduslikele aspektidele. Ja personaliarendustöötaja kogeb sageli teatud professionaalset deformatsiooni: ta näeb, kuidas seda müüa, kuid ei saa tegelikult aru, miks see nii on üles ehitatud. Ja konverentsile esitatakse ettekanne, mis on pooletunnine puhtalt turunduslik kõne sellest, mis head süsteem kaasa toob, ega sisalda sõnagi selle toimimise kohta. Kuid see on just kõige huvitavam ja olulisem! Kuidas see on korraldatud? Miks see nii on? Milliseid kehastusi ta koges ja mis talle varasemates teostustes ei sobinud?
Kui loote tootele ilusa ümbrise, saate selle lühikeseks ajaks kasutajatele pakkuda. Kuid huvi kaob kiiresti. Kui teadmusjuhtimise projekti elluviija ei saa aru selle “lihast”, mõtleb numbrites ja mõõdikutes, mitte sihtrühma tegelikes probleemides, siis tuleb langus väga kiiresti.
Tulles konverentsile sellise ettekandega, mis näeb välja nagu reklaambrošüür, pead mõistma, et see ei ole teie ettevõttest “väljaspool” huvitav. Inimesed, kes teid kuulama tulid, on idee juba ostnud (tegelikult maksid nad osalemise eest palju raha!). Neid ei pea veenma, et CT-ga on põhimõtteliselt vaja tegeleda. Neile tuleb öelda, kuidas seda teha ja kuidas mitte teha ning miks. See ei ole teie tippjuhtkond, teie boonus ei sõltu saalis olevast publikust.
Ja ometi on need ka ühe projekti kaks osa ja ilma hea ettevõttesisese reklaamita jääb ka kõige lahedam sisu veel üheks Sharepointiks. Ja kui sa ütled mulle kui müüte oma kolleegidele KM-i idee, mis töötab ja mis mitte ja miks, siis on lugu väga-väga väärtuslik.
Kuid võimalik on ka teine äärmus: lõime kõige lahedama baasi, kasutasime selliseid arenenud praktikaid, kuid millegipärast töötajad sinna ei läinud. Seetõttu olime selles mõttes pettunud ja lõpetasime selle tegemise. Meilgi oli selliseid soove. Miks töötajad ei toetanud? Võib-olla nad tõesti ei vajanud seda teavet (see on sihtrühma uurimise probleem, selle kohta tuleks kirjutada eraldi postitus). Või äkki suheldi nendega lihtsalt halvasti? Kuidas nad seda üldse tegid? Teadmusjuhtimise juht on ka hea PR-spetsialist. Ja kui ta teab, kuidas säilitada tasakaal reklaamimise ja sisu kasulikkuse vahel, on tal suur eduvõimalus. Sa ei saa rääkida ühest, unustades samas teise.
Arvud
Ja lõpuks numbrite kohta. Lugesin ühel konverentsil (mitte KnowledgeConf!) esineja memost, et publik armastab eksklusiivset teavet – numbreid. Aga miks? Enne seda konverentsi mõtlesin kaua, kuidas võiks minu numbritest publikule kasu olla? Kuidas aitab mu kolleege see, et mul õnnestus teadmusjuhtimise kaudu mõnda töötajate tootlikkuse näitajat N% võrra parandada? Mida teevad mu kuulajad homme teisiti, kui nad teavad mu numbreid? Ma esitasin ainult ühe argumendi: “Mulle meeldis üks teie praktika, tahan selle ise ellu viia, aga pean idee juhile maha müüma. Homme ütlen talle, et ettevõttes X viis see näitajate sellise tõusuni, et ta ostis selle idee ära.. Kuid mitte kõik minu tulemusnäitajad ei ole rakendatavad ühegi teise ettevõtte puhul. Võib-olla oskate aruannetes toodud arvude kasuks veel mingeid argumente pakkuda? Kuid minu arvates ei ole hea mõte kulutada 10 minutit 30-minutilisest aruandest numbritele, kui saaksite need kulutada praktilistele näidetele või isegi väikesele seminarile koos publikuga, IMHO.
Ja meile anti ka numbreid täis aruandeid. Pärast esimest arutelu palusime esinejatel rääkida praktikatest, mis selliste tulemusteni viisid. Neist, kes lõpuks lõppprogrammi jõudsid, olid aruanded, mis erinesid peaaegu täielikult algsest versioonist. Selle tulemusena oleme juba kuulnud palju tagasisidet selle tohutu praktilise baasi kohta, mille konverents pakkus. Ja keegi pole veel öelnud, et "oli huvitav teada saada, kui palju ettevõte X teadmusjuhtimise kaudu säästis."
Selle pika lugemise lõpetuseks tahaksin taaskord rõõmustada, et IT-maailm on mõistnud teadmusjuhtimise tähtsust ning loodan, et hakkab seda lähiajal aktiivselt juurutama, optimeerima ja kohandama. Ja Habrel tuleb teadmusjuhtimisele pühendatud eraldi keskus ja kõik meie esinejad jagavad teadmisi sealsete kolleegidega. Seni saate tutvuda kiirsõnumite, Facebooki ja muude saadaolevate suhtlusvahendite praktikatega. Soovime teile kõigile ainult kasulikke aruandeid ja edukaid kõnesid!
Allikas: www.habr.com