Salut tuturor. După a trecut deja o jumătate de an, timp în care am avut ocazia să susțin prezentări la alte două conferințe și să predau despre managementul cunoștințelor în două mari companii IT. Comunicând cu colegii, am realizat că în domeniul IT se poate vorbi deocamdată despre managementul cunoștințelor la nivel de „începător”, adică pur și simplu să conștientizăm că managementul cunoștințelor este necesar pentru orice departament al oricărei companii. Astăzi va fi minim din experiența mea personală – aș dori să discut despre standardele internaționale existente în domeniul managementului cunoștințelor.
Să începem, probabil, cu cel mai popular brand din domeniul standardizării – ISO. Imaginați-vă, există un standard dedicat complet sistemelor de management al cunoștințelor (ISO 30401:2018). Dar astăzi nu aș vrea să mă opresc asupra lui. Înainte de a ne ocupa de „cum” ar trebui să arate și să funcționeze un sistem de management al cunoștințelor, trebuie să convenim că acesta este, în principiu, necesar.
Să luăm, de exemplu, ISO 9001:2015 (Sisteme de management al calității). Așa cum sugerează numele, este un standard dedicat sistemului de management al calității. Pentru a obține certificarea pe baza acestui standard, o organizație trebuie să asigure transparența și continuitatea proceselor de lucru și a produselor și/sau serviciilor livrate. Cu alte cuvinte, certificatul înseamnă că în compania dumneavoastră totul funcționează clar, coordonat, înțelegeți care sunt riscurile implicate în organizarea proceselor curente, știți cum să controlați aceste riscuri și vă străduiți să le minimizați.
Ce legătură are managementul cunoștințelor cu aceasta? Ei bine, iată:
7.1.6 Cunoștințele organizației
Organizația trebuie să identifice cunoștințele necesare pentru funcționarea proceselor sale și pentru a atinge conformitatea produselor și serviciilor.
Cunoștințele trebuie să fie menținute și accesibile în volumul necesar.
În considerarea nevoilor și tendințelor în schimbare, organizația trebuie să țină cont de cunoștințele pe care le are și să stabilească modul în care să obțină sau să asigure accesul la cunoștințe suplimentare și actualizarea acestora.
OBSERVAȚIE 1. Cunoștințele organizației sunt cunoștințe specifice organizației; obținute în principal pe baza experienței.
Cunoștințele sunt informații care sunt utilizate și schimbate pentru a atinge obiectivele organizației.
OBSERVAȚIE 2. Baza cunoștințelor organizației poate fi:
a) surse interne (de exemplu, proprietate intelectuală; cunoștințe obținute din experiență; concluzii extrase din proiecte eșuate sau de succes; colectarea și schimbul de cunoștințe și experiențe nedocumentate; rezultatele îmbunătățirilor proceselor, produselor și serviciilor);
b) surse externe (de exemplu, standarde, comunitatea științifică, conferințe, cunoștințe obținute de la consumatori și furnizori externi).
Și mai jos, în anexe:
Cerințele referitoare la cunoștințele organizației au fost introduse cu scopul de a:
a) proteja organizația de pierderea cunoștințelor, de exemplu, din cauza:
- fluctuației de personal;
- imposibilității de a obține și schimba informații;
b) încurajarea organizației să dobândească cunoștințe, de exemplu, pe baza:
- învățării din propria experiență;
- mentorării;
- benchmarking-ului.
Așadar, standardul ISO în domeniul managementului calității afirmă că, pentru a asigura calitatea activităților sale, întreprinderea trebuie să se ocupe de managementul cunoștințelor. Exact așa, fără alternativă – „trebuie”. Altfel, nonconformitate, și la revedere. Acest fapt sugerează deja că acesta nu este un aspect opțional în organizație, cum este adesea considerat managementul cunoștințelor în IT, ci o componentă obligatorie a proceselor de afaceri.
Mai mult decât atât, standardul explică ce riscuri trebuie să elimine managementul cunoștințelor. De fapt, acestea sunt destul de evidente.
Să ne imaginăm... nu, nu așa – vă rog să vă amintiți o situație din cariera dumneavoastră când ați avut nevoie urgentă de o informație pentru muncă, iar singurul său deținător era în acel moment în vacanță/călătorie de afaceri, a plecat din companie sau pur și simplu era bolnav. Ați reușit să vă amintiți? Cred că aproape oricare dintre noi a avut de-a face cu asta. Ce ați simțit în acel moment?
Dacă, după un timp, conducerea departamentului va analiza întârzierea proiectului, cu siguranță va găsi un vinovat și se va liniști cu asta. Însă, personal pentru dumneavoastră, în momentul când cunoștințele erau necesare, conștientizarea că „vinovat este RM, care a plecat în Bali și nu a lăsat nicio instrucțiune în caz de întrebări” nu v-a ajutat deloc. Sigur că el este de vină. Dar această problemă nu vă va ajuta să o rezolvați.
Dacă cunoștințele sunt documentate într-un sistem accesibil persoanelor care le-ar putea folosi, atunci povestea „de vacanță” devine practic imposibilă. Astfel, continuitatea proceselor de afaceri este asigurată, iar concediile, plecările angajaților și acel binecunoscut factor de bus nu reprezintă o problemă pentru companie – calitatea produsului/serviciului va rămâne la nivelul său obișnuit.
Dacă în companie există o platformă pentru schimbul și stocarea informațiilor și experienței, iar o cultură (obicei) de utilizare a acestei platforme s-a format, angajații nu trebuie să aștepte câteva zile un răspuns de la un coleg (sau să-l caute timp de câteva zile) și să își pună astfel sarcinile pe hold.
De ce vorbesc despre obișnuință? Pentru că este insuficient să faci o bază de cunoștințe pentru a începe să fie utilizată. Ne-am obișnuit să căutăm răspunsuri la întrebările noastre pe Google, iar intranetul se asociază adesea cu cererile de concediu și panoul de anunțuri. Nu avem obișnuința de a „căuta informații despre cadrele Agile” (de exemplu) pe intranet. Prin urmare, chiar dacă într-o secundă am avea cea mai grozavă bază de cunoștințe, nimeni nu se va apuca să o folosească în secunda următoare (sau chiar în următoarea lună) – nu există obișnuință. Schimbarea obiceiurilor este dureroasă și necesită timp. Nu toți sunt pregătiți pentru asta. Mai ales după 15 ani în care „așa s-au desfășurat lucrurile”. Dar fără asta, inițiativa de gestionare a cunoștințelor din companie este sortită eșecului. De aceea, maeștrii în domeniul gestionării cunoștințelor leagă strâns gestionarea cunoștințelor de gestionarea schimbărilor.
De asemenea, merită menționat că „Atunci când se evaluează nevoile și tendințele în schimbare, organizația trebuie să ia în considerare cunoștințele pe care le are...”, adică să dezvolte o cultură a recursului la experiența anterioară atunci când ia decizii în condiții de lume în schimbare. Și observați, din nou „trebuie”.
Apropo, acest punct mic din standard vorbește foarte mult despre experiență. De obicei, atunci când se discută despre gestionarea cunoștințelor, stereotipurile sugerează o imagine a unei baze de cunoștințe cu sute de documente, organizate sub formă de fișiere (reguli, cerințe). Dar ISO vorbește despre experiență. Cunoștințele acumulate pe baza experienței anterioare a companiei și a fiecărui angajat sunt ceea ce permite evitarea riscului de a repeta greșelile, de a lua decizii mai profitabile și chiar de a crea un nou produs. În companiile cele mai mature în domeniul gestionării cunoștințelor (inclusiv cele rusești, de altfel), gestionarea cunoștințelor este privită ca un instrument pentru creșterea capitalizării companiei, crearea de noi produse, dezvoltarea de noi idei și optimizarea proceselor. Aceasta nu este o bază de cunoștințe, ci un mecanism pentru inovație. Să ne aprofundăm în acest subiect Ghidul PMBOK al organizației PMI.
PMBOK este un ghid privind cadrul de cunoștințe în managementul proiectelor, cartea de bază a PM. În cea de-a șasea ediție (2016) a acestui ghid a apărut un capitol dedicat gestionării integrării proiectului, care include, la rândul său, o subsecțiune despre gestionarea cunoștințelor proiectului. Această secțiune a fost creată «pe baza comentariilor utilizatorilor ghidului», adică a devenit un produs al experienței de utilizare a versiunilor anterioare ale ghidului în condiții reale. Și realitatea a cerut gestionarea cunoștințelor!
Principala ieșire a noului punct este «Registrul lecțiilor învățate» (care, de altfel, este menționat și în standardul ISO descris mai sus). De asemenea, conform ghidului, întocmirea acestui registru trebuie să se facă pe întreaga durată de implementare a proiectului, și nu doar la final, când vine timpul să se analizeze rezultatul. În opinia mea, aceasta se leagă foarte mult de retrospectiva din agile, dar voi scrie un post separat despre asta. Textul din PMBOK sună astfel:
Gestionarea cunoștințelor proiectului este un proces de utilizare a cunoștințelor existente și de creare a unor noi cunoștințe pentru a atinge obiectivele proiectului și pentru a facilita învățarea în organizație.
Domeniul de cunoștințe «gestionarea integrării proiectului» necesită integrarea rezultatelor obținute în toate celelalte domenii de cunoștințe.
Tendințele emergente în procesele de integrare includ, printre altele:
…
• Managementul cunoștințelor proiectului
Caracterul din ce în ce mai mobil și schimbabil al forței de muncă necesită un proces mai riguros de identificare a cunoștințelor pe parcursul întregului ciclu de viață al proiectului și transferul lor către audiențele țintă, pentru a evita pierderea acestora.
***
Beneficiile cheie ale acestui proces constau în utilizarea cunoștințelor dobândite anterior de organizație pentru a obține sau îmbunătăți rezultatele proiectului, iar cunoștințele acumulate în cadrul proiectului curent rămân accesibile pentru a sprijini activitatea operațională a organizației și proiectele sau etapele viitoare. Acest proces se desfășoară pe parcursul întregului proiect.
Nu voi copia întreaga secțiune mare din ghid aici. Poate fi consultată individual și se pot face concluziile corespunzătoare. Citatele prezentate mai sus, după părerea mea, sunt suficiente. Cred că existența unui astfel de grad de detaliere în sarcina PM-ului de gestionare a cunoștințelor proiectului deja reflectă importanța acestui aspect în cadrul lucrului la proiecte. Apropo, aud adesea teză: „Cui îi sunt utile cunoștințele noastre în alte departamente?” Adică, cui îi sunt utile aceste lecții extrase?
În realitate, este frecvent vizibil faptul că subdiviziunea se percepe pe sine ca un „unitate în vid”. Avem noi cu biblioteca noastră, iar restul companiei nu are nevoie de cunoștințe despre biblioteca noastră. Despre biblioteca – poate. Dar despre procesele conexe?
Un exemplu banal: pe parcursul lucrului la proiect s-a interacționat cu un contractor. De exemplu, cu un designer. Contractorul s-a dovedit a fi cam slab, a întârziat termenele și a refuzat să finalizeze fără plată suplimentară. PM-ul a înregistrat în registrul lecțiilor extrase că nu ar trebui să lucrăm cu acest contractor nesigur. În același timp, în marketing căutau și ei un designer și s-au întâlnit cu același contractor. Și în acest moment sunt două opțiuni:
a) dacă în companie este bine stabilită cultura reutilizării experienței, colegul din marketing va căuta în registrul lecțiilor extrase dacă cineva a mai colaborat deja cu acest contractor, va vedea feedback-ul negativ de la PM-ul nostru și nu va pierde timp și bani comunicând cu acest contractor nesigur.
b) dacă în companie nu există o astfel de cultură, marketerul se va adresa aceluiași contractor nesigur, va pierde banii companiei, timp și poate va deranja o campanie promoțională importantă și urgentă, de exemplu.
Care variantă pare mai de succes? Și observăm că informația utilă nu a fost despre produsul dezvoltat, ci despre procesele conexe dezvoltării. Și s-a dovedit a fi utilă nu pentru un alt RM, ci pentru un angajat dintr-un domeniu complet diferit. Din aceasta derivă concluzia: nu putem considera dezvoltarea separată de vânzări, suport tehnic separat de analiza de afaceri, și IT-ul separat de AHC. Toți din companie au experiență de muncă care poate fi utilă altcuiva în companie. Și nu este neapărat nevoie ca aceștia să fie reprezentanți ai direcțiilor conexe.
Cu toate acestea, și aspectul tehnic al proiectului poate fi util. Încercați să faceți un audit al proiectelor din compania dumneavoastră în ultimii câțiva ani. Veți fi surprins câte biciclete au fost inventate în soluționarea unor sarcini similare. De ce? Pentru că procesele de schimb de cunoștințe nu sunt stabilite.
Așadar, managementul cunoștințelor, conform ghidului PMI, este una dintre sarcinile RM-ului. După cum vedem, două organizații cunoscute care oferă certificări plătite după standardele lor includ managementul cunoștințelor în listele de instrumente esențiale pentru controlul calității și desfășurarea proiectelor. De ce managerii din companiile IT consideră în continuare că managementul cunoștințelor este documentarea? De ce centrele de schimb de cunoștințe rămân apa de la răcitor și fumatul? Totul se reduce la înțelegere și obiceiuri. Sper că în mod treptat înțelegerea domeniului managementului cunoștințelor va crește și în rândul managerilor IT, iar tradiția verbală va înceta să fie instrumentul de păstrare a cunoștințelor în companie. Studiați standardele muncii dumneavoastră – conțin multe lucruri interesante!
Sursa: habr.com
