Teadmiste juhtimine rahvusvaheliste standardite järgi: ISO, PMI

Tere kõigile. Pärast KnowledgeConf 2019 on möödunud juba kuus kuud, selle aja jooksul olen ma esinenud veel kahel konverentsil ja pidanud loenguid teadmusjuhtimise teemal kahel suurel IT-ettevõttel. Suheldes kolleegidega, sain aru, et IT-sektoris saab veel rääkida teadmusjuhtimisest tasemel „algaja”, täpsemalt, lihtsalt mõista, et teadmusjuhtimine on vajalik igale osakonnale igas ettevõttes. Täna on minu isikliku kogemuse minimaalne maht – soovin käsitleda olemasolevaid rahvusvahelisi standardeid teadmusjuhtimise valdkonnas.

Alustame ehk kõige populaarsemast brändist standardiseerimise alal – ISO. Kujutage ette, et on olemas terve eraldi standard, mis on pühendatud teadmisjuhtimise süsteemidele (ISO 30401:2018). Kuid täna ma ei jää selle juurde. Enne kui hakkame mõtlema, kuidas peaks teadmusjuhtimise süsteem välja nägema ja töötama, peab olema kokkulepe, et see on üldiselt vajalik.

Võtame näiteks, ISO 9001:2015 (Kvaliteedihaldussüsteemid). Nagu nimigi viitab, on see standard, mis käsitleb kvaliteedihaldussüsteemi. Selle standardi alusel sertifitseerimiseks peab organisatsioon tagama tööprotsesside ja toodete ja/või teenuste läbipaistvuse ja katkestusteta. Teisisõnu, see tunnustus tähendab, et teie ettevõttes on kõik sujuvalt ja efektiivselt toimiv, te mõistate, millised riskid on seotud praeguste protsessidega, teate, kuidas neid riske kontrollida ja püüate neid minimeerida.

Kuidas seondub see teadmiste juhtimisega? Just nii:

7.1.6 Organisatsiooni teadmised

Organisatsioon peab määrama vajalikud teadmised oma protsesside toimimiseks ning toodete ja teenuste vastavuse saavutamiseks.

Teadmised peavad olema säilitatud ja vajalikus ulatuses kergesti kättesaadavad.

Muutuvate vajaduste ja suundumuste arvesse võtmisel peab organisatsioon arvesse võtma oma teadmisi ning määrama, kuidas omandada või tagada juurdepääs täiendavatele teadmistele ja nende ajakohastamiseks.

MÄRKUS 1. Organisatsiooni teadmus on organisatsioonile spetsiifiline teadmus, mis tuleneb peamiselt kogemusest.

Teadmised on teave, mida kasutatakse ja millega vahetatakse, et saavutada organisatsiooni eesmärke.

MÄRKUS 2. Organisatsiooni teadmiste aluseks võivad olla:

a) sisemised allikad (nt intellektuaalne omand; kogemusest saadud teadmised; järeldused, mis on saadud ebaõnnestunud või eduka projekti põhjal; mitte-dokumenteeritud teadmiste ja kogemuste kogumine ja vahetus; protsesside, toodete ja teenuste parandamise tulemused);

b) välised allikad (nt standardid, teaduslik kogukond, konverentsid, tarbijatest ja välistest tarnijatest saadud teadmised).

Ja allpool, lisades:

Organisatsiooni teadmisi käsitlevad nõuded on sisse viidud eesmärgiga:

a) kaitsta organisatsiooni teadmiste kadumise eest, näiteks:

• töötajate voolavus;
• info hankimise ja vahetamise võimatuse tõttu;

b) julgustada organisatsiooni teadmiste omandamise poole, näiteks:

• oma kogemusest õppimise kaudu;
• mentorluse kaudu;
• benchmarkingu kaudu.

Nii et kvaliteedihalduse standard ISO väidab, et ettevõte peab oma tegevuse kvaliteedi tagamiseks tegelema teadmiste juhtimisega. Just nii, alternatiivideta – „peab“. Vastasel juhul nonconformity ja head aega. Juba see üks fakt viitab, et see pole organisatsioonis valikuline aspekt, nagu teadmiste juhtimist IT-valdkonnas sageli käsitletakse, vaid äriprotsesside kohustuslik element.

Veelgi enam, standard kirjeldab, milliseid riske teadmiste juhtimine püüab kõrvaldada. Tegelikult on need täiesti ilmsed.

Kujutage ette… ei, mitte nii – meenutage palun olukorda oma karjäärist, kui teil oli tööl hädasti vaja mingit teavet, aga selle ainus hoidja oli sel hetkel puhkusel/äri reisil, lõpetas ettevõtte või lihtsalt haigestus. Kas meenutasite? Ma arvan, et enamik meist on sellise olukorraga kokku puutunud. Mida te sel hetkel tundsite?

Kui mingi aja pärast hakkab osakonna juht koosolekul arutama projekti tähtaegade edasilükkamist, leiab ta kindlasti süüdlase ja sellega rahuldub. Kuid teid isiklikult ei aita see hetk, kui teadmisi oli vaja, kuid teadsid, et 'süüdi on projektijuht, kes läks Bali ja ei jätnud mingeid juhiseid küsimuste korral'. Loomulikult on ta süüdi. Kuid see ei aita teil oma ülesannet lahendada.

Kui teadmised on dokumenteeritud süsteemis, mis on kätte saadav inimestele, kellele need võivad olla vajalikud, siis muutub kirjeldatud 'puhkuse' lugu praktiliselt võimatuks. Nii tagatakse äriprotsesside järjepidevus ja seega ei ole ettevõttele hirmu tööjõu puhkuste, lahkumiste ja nii-öelda 'bus factor' ees – toote/teenuse kvaliteet jääb oma tavapärasele tasemele.

Kui ettevõttes on teabe ja kogemuste vahetamiseks ning säilitamiseks koht, samuti on kujundatud kultuur (harjumus) selle koha kasutamiseks, siis ei pea töötajad ootama mitu päeva vastust kolleegilt (või isegi mitu päeva otsima seda kolleegi) ja panema seetõttu oma ülesanded ootele.

Miks ma räägin harjumustest? Sest pelgalt teadmistebaasi loomine ei garanti, et sellest hakatakse ka kasutama. Me kõik oleme harjunud otsima vastuseid oma küsimustele Googlest, samas kui intranet seondub enamasti puhkuseavalduste ja teadetetahvlitega. Meil pole harjumust „otsida teavet Agile raamide kohta“ (näiteks) inimeste intranetist. Seetõttu, isegi kui meil tekib hetkega erakordne teadmistebaas, ei hakka keegi seda järgmisel sekundil (ja isegi järgmisel kuul) kasutama – harjumust pole. Oma harjumuste muutmine on valulik ja aeganõudev. Kõik sellele ei valmis ole. Eriti kui on 15 aastat „niimoodi töötatud“. Kuid ilma selleta ootab ettevõtte teadmistehaldus algatust ebaõnnestumist. Just seetõttu seovad teadusguruid teadmiste haldamise muutuste haldamise (change management) lahutamatult.

Tasub tähelepanu pöörata ka sellele, et „Muutuvaid vajadusi ja suundi arvesse võttes peab organisatsioon arvestama olemasolevat teadmust…“, st välja töötama kultuuri, mis kutsub üles kasutama varasemaid kogemusi otsuste tegemisel muutuvas maailmas. Ja märkige, taas „peab“.

Üldiselt räägitakse selle standardi üksikasja puhul palju kogemusest. Tüüpiliselt, kui räägitakse teadmusjuhtimisest, hakkavad stereotüübid esitlema teadmistebaasi kujutist, mis koosneb sadadest dokumentidest, mis on seotud failide (reeglite, nõuete) vormis. Kuid ISO räägib kogemusest. Teadmised, mis on saadud ettevõtte ja iga selle töötaja varasemast kogemusest, võimaldavad vältida riskide kordamist, teha kiireid ja kasumlikumaid otsuseid ning isegi luua uusi tooteid. Ainuüksi kõige küpsemates teadmusjuhtimise valdkonnas ettevõtetes (sealhulgas ka Venemaal) nähakse teadmusjuhtimist kui vahendit ettevõtte kapitaliseerimise suurendamiseks, uute toodete loomiseks, uute ideede arendamiseks ja protsesside optimeerimiseks. See ei ole teadmistebaas, see on innovatsiooni mehhanism. Sügavamateks arusaamisteks aitab meid PMI organisatsiooni PMBOK juhend.

PMBOK – see projektihalduse teadmiste kogumise käsiraamat, PM-a käsiraamat. Kuuendas väljaandes (2016) lisati sellele käsiraamatule peatükk, mis käsitleb projekti integreerimise juhtimist, sealhulgas alapeatükk projekti teadlikkuse juhtimise kohta. See punkt loodi „käsiraamatu kasutajate kommentaaride põhjal“, st see sai eelmiste versioonide suhtes reaalse kasutuse põhjal koostatud kogemuste tulemuseks. Ja tegelikkus nõudis teadlikkuse juhtimist!

Uue punkti peamine väljund on „Kogutud õppetundide register“ (millele viidatakse ka eespool mainitud ISO standardis). Samuti peab käsiraamatu kohaselt selle registri koostamine toimuma kogu projekti elluviimise ajal, mitte alles pärast seda, kui on aeg tulemusi analüüsida. Minu arvates on see väga sarnane tuhandeid, kuid sellest kirjutan ma eraldi postituses. Sõnasõnaliselt kõlab tekst PMBOK-is nii:

Projekti teadlikkuse juhtimine on olemasolevate teadmiste kasutamise ja uute teadmiste loomise protsess, et saavutada projekti eesmärke ja soodustada organisatsiooni õppimist.

Teema "projekti integreerimise juhtimine" nõuab tulemuste ühendamist, mis on saadud kõigis teistes teadmiste valdkondades.

Integreerimisprotsesside arenevad suundumused hõlmavad muu hulgas:

…

• Projekti teadmiste juhtimine

Töötajate üha liikuvam ja vahetatavam olemus nõuab rangemat teadmiste määratlemise ja edastamise protsessi projekti kogu eluaja vältel, et vältida teadmiste kaotamist sihtrühmadele.

***

Selle protsessi peamised eelised seisnevad selles, et organisatsioonis varasemalt omandatud teadmisi kasutatakse projekti tulemuste saavutamiseks või parandamiseks, samas kui käimasoleva projekti käigus saadud teadmised jäävad kergesti kättesaadavaks organisatsiooni operatiivsete tegevuste ja tulevaste projektide või nende etappide toetamiseks. See protsess toimub kogu projekti vältel.

Ma ei hakka siia kopeerima kogu suure juhendi osa. Sellega saab tutvuda iseseisvalt ja teha vastavad järeldused. Ülalpool esitatud tsitaate on minu arvates täiesti piisavalt. Minu arvates ütleb juba sellise detailitsemise olemasolu PRMi ülesande definitsioonis, kui oluline on see aspekt projektide töö juures. Muide, kuulen tihti väidet: "Kellele meie teadmised teiste osakondade jaoks vajalikud on?" See tähendab, kellele on vajalikud need väljavõetud õppetunnid?

Tegelikult võib sageli näha, et osakond peab end kui "üksuseks vaakumis". Siin oleme meie oma raamatukoguga ja siin on kogu ülejäänud ettevõte, ning teadmised meie raamatukogu kohta ei ole neile kuidagi vajalikud. Raamatukogu kohta - võib-olla. Aga samasuguste protsesside kohta?

Lihtne näide: projekti käigus toimus koostöö alltöövõtjaga. Näiteks disaineriga. Alltöövõtja ei olnud just parim valik, ta ei suutnud tähtaegadest kinni pidada ja keeldus täiendavate muudatuste tegemisest ilma lisatasuta. Projektijuht registreeris saadud õppetunnid, et sellise ebausaldusväärse alltöövõtjaga ei tasu töötada. Sel ajal otsis turundusosakond ka disainerit ja sattus sama alltöövõtja peale. Siinkohal on kaks varianti:

a) kui ettevõttes on hea kogemuste jagamise kultuur, siis turundusspetsialist otsib välja õppetundide registrist, kas keegi on juba selle alltöövõtjaga kokku puutunud, näeb meie projektijuhi negatiivset tagasisidet ning ei kaota aega ja raha, suheldes ebausaldusväärse alltöövõtjaga.

b) kui ettevõttes ei ole sellist kultuuri, pöördub turundaja sama ebausaldusväärse alltöövõtja poole, kaotab ettevõtte raha, aega ja võib olulise ja kiire reklaamikampaania ära rikkuda, näiteks.

Milline variant tundub edumeelne? Tähelepanu, kasulik ei olnud teave arendatava toote kohta, vaid arendamisele nähtud protsesside kohta. Ja see oli kasulik mitte teisele PM-ile, vaid täiesti erineva valdkonna töötajale. Seega järeldus: arendust ei saa käsitleda eraldi müügist, tehnilisest toest ärianalüüsist ning IT-d mitte AHT-st. Kõigil ettevõttes on töökogemus, mis osutub kellelegi teisele kasulikuks. Ja see ei pea tingimata olema seotud naabervaldkondade esindajatega.

Sellegipoolest võib ka projekti tehniline külg osutuda kasulikuks. Proovige teha audit oma ettevõtte projektidest viimase paariaasta jooksul. Teid üllatab, kui palju jalgrattaid on sarnaste probleemide lahendamiseks välja mõeldud. Miks? Sest teadmiste vahetamise protsessid ei ole paika pandud.

Seega, teadmiste haldamine, vastavalt PMI juhendile, on üks PM-i ülesandeid. Nagu näeme, on kaks tuntud organisatsiooni, mis pakuvad tasulisi sertifikaate oma standardite kohaselt, lisanud teadmiste juhtimise kvaliteedikontrolli ja projektitöö must-have tööriistade nimekirja. Miks arvavad aga IT-ettevõtete juhid endiselt, et teadmiste haldamine on dokumenteerimine? Miks jäävad teadmiste vahetamise keskusteks veepump ja suitsetamisala? Kõik sõltub arusaamadest ja harjumustest. Loodan, et teadmiste haldamise valdkonna mõistmine IT-juhtide seas kasvab järk-järgult ning suuline traditsioon ei jää enam teadmiste säilitamise tööriistaks ettevõttes. Uurige oma tööstandardeid – seal on palju huvitavat!

Allikas: habr.com