Salutare tuturor. După Au trecut șase luni, timp în care am reușit să vorbesc la încă două conferințe și să susțin prelegeri pe tema managementului cunoștințelor în două mari companii IT. Comunicând cu colegii, mi-am dat seama că în IT încă se poate vorbi despre managementul cunoștințelor la nivel de „începător”, sau mai bine zis, doar să realizez că managementul cunoștințelor este nevoie de orice departament al oricărei companii. Astăzi va exista un minim de experiență proprie - aș dori să iau în considerare standardele internaționale existente în domeniul managementului cunoștințelor.
Să începem cu probabil cel mai popular brand din domeniul standardizării - ISO. Imaginați-vă, există un standard complet separat dedicat sistemelor de management al cunoștințelor (ISO 30401:2018). Dar astăzi nu m-aș opri asupra ei. Înainte de a înțelege „cum” ar trebui să arate și să funcționeze un sistem de management al cunoștințelor, trebuie să fiți de acord că, în principiu, este necesar.
Să luăm, de exemplu, ISO 9001: 2015 (Sisteme de management al calității). După cum sugerează și numele, acesta este un standard dedicat sistemelor de management al calității. Pentru a fi certificată conform acestui standard, o organizație trebuie să se asigure că procesele sale de afaceri și produsele și/sau serviciile sunt transparente și fără întreruperi. Cu alte cuvinte, certificatul înseamnă că totul în compania dumneavoastră funcționează clar și fără probleme, înțelegeți ce riscuri prezintă organizarea actuală a proceselor, știți să controlați aceste riscuri și vă străduiți să le minimizați.
Ce legătură are managementul cunoștințelor cu el? Iată ce are de-a face cu el:
7.1.6 Cunoștințe organizaționale
Organizația trebuie să stabilească cunoștințele necesare pentru a-și opera procesele și pentru a obține conformitatea produselor și serviciilor.
Cunoștințele trebuie menținute și puse la dispoziție în măsura în care este necesar.
Atunci când ia în considerare nevoile și tendințele în schimbare, organizația trebuie să ia în considerare cunoștințele sale existente și să determine cum să obțină sau să ofere acces la cunoștințe suplimentare și să le actualizeze.
NOTA 1: Cunoștințele organizaționale sunt cunoștințe specifice unei organizații; în mare parte derivate din experienţă.
Cunoștințele sunt informații care sunt folosite și schimbate pentru a atinge obiectivele organizaționale.
NOTA 2 Baza de cunoștințe a unei organizații poate fi:
a) surse interne (de exemplu, proprietate intelectuală; cunoștințe dobândite din experiență; lecții învățate din proiecte eșuate sau de succes; colectare și schimb de cunoștințe și experiență nedocumentate; rezultate ale îmbunătățirii proceselor, produselor și serviciilor);
b) surse externe (de exemplu, standarde, mediul academic, conferințe, cunoștințe acumulate de la clienți și furnizori externi).
Și mai jos, în atașamente:
Cerințele de cunoștințe organizaționale au fost introduse pentru:
a) protejarea organizației de pierderea cunoștințelor, de exemplu din cauza:
- fluctuația personalului;
- incapacitatea de a obține și a face schimb de informații;
b) încurajarea organizației să dobândească cunoștințe, de exemplu prin:
- învățare prin practică;
- mentorat;
- benchmarking.
Deci, standardul ISO în domeniul managementului calității prevede că pentru a-și asigura calitatea activităților, o întreprindere trebuie să se angajeze în managementul cunoștințelor. Așa e, nu există alternativă - "trebuie sa". In rest nonconformism, si la revedere. Numai acest fapt pare să sugereze că acesta nu este un aspect opțional în organizație, deoarece managementul cunoștințelor în IT este adesea tratat, ci o componentă obligatorie a proceselor de afaceri.
Mai mult, standardul descrie ce riscuri este conceput pentru a elimina managementul cunoștințelor. De fapt, sunt destul de evidente.
Să ne imaginăm... nu, nu așa - vă rog să vă amintiți o situație din carieră când ați avut nevoie de informații pentru muncă, iar singurul operator era în acel moment în vacanță/călătorie de afaceri, a părăsit complet compania sau pur și simplu era bolnav . Vă amintiți? Cred că aproape toți am avut de-a face cu asta. Cum te-ai simțit în acel moment?
Dacă, după ceva timp, conducerea departamentului analizează nerespectarea termenelor limită ale proiectului, va găsi, desigur, pe cineva pe care să-l învinuiască și să se calmeze pentru asta. Dar pentru tine personal, în momentul în care aveai nevoie de cunoștințe, înțelegerea că „de vină este RM, care a plecat în Bali și nu a lăsat nicio instrucțiune în caz de întrebări”. Bineînțeles că el este de vină. Dar acest lucru nu va ajuta la rezolvarea problemei dvs.
Dacă cunoștințele sunt documentate într-un sistem accesibil persoanelor care ar putea avea nevoie de ele, atunci povestea „stațiunii” descrisă devine aproape imposibilă. Astfel, se asigură continuitatea proceselor de afaceri, ceea ce înseamnă că vacanțele, plecările angajaților și notoriul factor autobuz nu reprezintă o amenințare pentru întreprindere - calitatea produsului/serviciului va rămâne la nivelul său obișnuit.
Dacă compania are o platformă pentru schimbul și stocarea de informații și experiență și, de asemenea, și-a format o cultură (obișnuință) de utilizare a acestei platforme, atunci angajații nu trebuie să aștepte câteva zile pentru un răspuns de la un coleg (sau chiar să caute câteva zile). pentru acest coleg) și pune-ți în așteptare sarcinile.
De ce vorbesc despre obiceiuri? Pentru că nu este suficient să creezi o bază de cunoștințe pentru ca oamenii să înceapă să o folosească. Cu toții suntem obișnuiți să căutăm răspunsuri la întrebările noastre pe Google și de cele mai multe ori asociem intranetul cu aplicațiile de vacanță și avizierele. Nu avem obiceiul să „căutăm informații despre framework-urile Agile” (de exemplu) pe intranet. Prin urmare, chiar dacă avem cea mai tare bază de cunoștințe într-o secundă, nimeni nu va începe să o folosească în secunda următoare (sau chiar în luna următoare) - nu există nici un obicei. Schimbarea obiceiurilor este dureroasă și necesită timp. Nu toată lumea este pregătită pentru asta. Mai ales dacă „au lucrat la fel” timp de 15 ani. Dar fără aceasta, inițiativa de cunoaștere a companiei va eșua. Acesta este motivul pentru care experții KM leagă în mod indisolubil managementul cunoștințelor cu managementul schimbării.
De asemenea, merită să acordați atenție faptului că „Când luați în considerare nevoile și tendințele în schimbare, o organizație trebuie să țină cont de cunoștințele sale existente...”, i.e. dezvoltarea unei culturi de referire la experiența anterioară atunci când luați decizii într-o lume în schimbare. Și observă din nou "trebuie sa".
Apropo, acest mic paragraf al standardului spune multe despre experiență. De obicei, când vine vorba de managementul cunoștințelor, stereotipurile încep să sugereze o imagine a unei baze de cunoștințe cu sute de documente plasate sub formă de fișiere (regulamente, cerințe). Dar ISO vorbește despre experiență. Cunoștințele dobândite din experiența trecută a companiei și a fiecărui angajați ai acesteia sunt cele care vă permit să evitați riscul de a repeta greșeli, să luați imediat decizii mai profitabile și chiar să creați un nou produs. În cele mai mature companii din domeniul managementului cunoștințelor (inclusiv cele rusești, de altfel), managementul cunoștințelor este considerat un mijloc de creștere a capitalizării companiei, crearea de noi produse, dezvoltarea de idei noi și optimizarea proceselor. Aceasta nu este o bază de cunoștințe, este un mecanism de inovare. Ne ajută să înțelegem acest lucru mai în detaliu Ghidul PMBOK al PMI.
PMB OK este un ghid pentru corpul de cunoștințe despre managementul proiectelor, un manual PM. Ediția a șasea (2016) a acestui ghid a introdus o secțiune despre managementul integrării proiectelor, care, la rândul său, include o subsecțiune despre managementul cunoștințelor de proiect. Acest paragraf a fost creat „pe baza comentariilor utilizatorilor manualului”, adică. a devenit produsul experienței în utilizarea versiunilor anterioare ale ghidului în condiții reale. Iar realitatea cerea managementul cunoștințelor!
Ieșirea principală a noului articol este „Registrul lecțiilor învățate” (în standardul ISO descris mai sus, de altfel, este menționat și acesta). Mai mult, conform conducerii, întocmirea acestui registru ar trebui efectuată pe toată durata implementării proiectului, și nu la finalizarea acestuia, când vine momentul analizării rezultatului. În opinia mea, acest lucru este foarte asemănător cu retrospectivele în agile, dar voi scrie o postare separată despre asta. Textul textual din PMBOK sună astfel:
Managementul cunoștințelor de proiect este procesul de utilizare a cunoștințelor existente și crearea de noi cunoștințe pentru a atinge obiectivele proiectului și pentru a promova învățarea în organizație
Zona de cunoștințe privind managementul integrării proiectelor necesită integrarea rezultatelor obținute din toate celelalte domenii de cunoștințe.
Tendințele emergente în procesele de integrare includ, dar nu se limitează la:
...
• Managementul cunoștințelor de proiect
Natura din ce în ce mai mobilă și în schimbare a forței de muncă necesită, de asemenea, un proces mai riguros pentru definirea cunoștințelor de-a lungul ciclului de viață al proiectului și transferarea acestora către publicul țintă, astfel încât cunoștințele să nu se piardă.
***
Beneficiile cheie ale acestui proces sunt că cunoștințele dobândite anterior ale organizației sunt folosite pentru a obține sau îmbunătăți rezultatele proiectului, iar cunoștințele dobândite din proiectul curent rămân disponibile pentru a sprijini operațiunile organizației și proiectele viitoare sau fazele acestora. Acest proces continuă pe tot parcursul proiectului.
Nu voi copia și lipi întreaga secțiune mare a manualului aici. Puteți să vă familiarizați cu el și să trageți concluziile adecvate. Citatele prezentate mai sus sunt, după părerea mea, destul de suficiente. Mi se pare că prezența unui astfel de detaliu în sarcina PM de a gestiona cunoștințele de proiect indică deja importanța acestui aspect atunci când se lucrează la proiecte. Apropo, aud adesea teza: „Cine are nevoie de cunoștințele noastre în alte departamente?” Adică, cine are nevoie de aceste lecții învățate?
De fapt, se vede adesea că o unitate se consideră o „unitate în vid”. Iată-ne cu biblioteca noastră, dar există restul companiei, iar cunoștințele despre biblioteca noastră nu îi sunt de nici un folos. Despre bibliotecă – poate. Dar procesele însoțitoare?
Un exemplu banal: în timpul lucrărilor la proiect a existat interacțiune cu antreprenorul. De exemplu, cu un designer. Antreprenorul s-a dovedit a fi așa, a ratat termenele limită și a refuzat să finalizeze lucrarea fără plată suplimentară. RM a consemnat în registrul lecțiilor învățate că nu a meritat să lucreze cu acest antreprenor nesigur. În același timp, undeva în marketing au căutat și un designer și au dat peste același antreprenor. Și în acest moment există două opțiuni:
a) dacă compania are o cultură bine stabilită a experienței de reutilizare, un coleg de la marketing se va uita în registrul de lecții învățate pentru a vedea dacă cineva a contactat deja acest contractant, va vedea feedback negativ de la PM-ul nostru și nu va pierde timpul și bani comunicând cu acest contractant nesigur.
b) în cazul în care compania nu are o astfel de cultură, marketerul se va adresa aceluiași contractor nesigur, va pierde banii, timpul companiei și poate perturba o campanie promoțională importantă și urgentă, de exemplu.
Care varianta pare mai reusita? Și rețineți că nu informațiile despre produsul în curs de dezvoltare au fost utile, ci despre procesele care însoțesc dezvoltarea. Și s-a dovedit a fi util nu unui alt RM, ci unui angajat dintr-o direcție complet diferită. De aici concluzia: dezvoltarea nu poate fi luată în considerare separat de vânzări, suport tehnic din analiza de afaceri și IT de managementul administrativ. Toată lumea din companie are experiență de lucru care va fi utilă altcuiva din companie. Și aceștia nu vor fi neapărat reprezentanți ai domeniilor conexe.
Cu toate acestea, partea tehnică a proiectului poate fi utilă. Încercați să auditați proiectele din compania dumneavoastră în ultimii ani. Vei fi surprins de câte biciclete au fost inventate pentru a rezolva probleme similare. De ce? Deoarece procesele de schimb de cunoștințe nu au fost stabilite.
Deci, managementul cunoștințelor, conform manualului PMI, este una dintre sarcinile PM. După cum putem vedea, două organizații binecunoscute care efectuează certificări plătite conform standardelor lor includ managementul cunoștințelor în listele lor de instrumente obligatorii pentru controlul calității și munca de proiect. De ce mai cred managerii din companiile IT că managementul cunoștințelor este documentare? De ce răcitorul și camera de fumat rămân centre de schimb de cunoștințe? Totul este o chestiune de înțelegere și obiceiuri. Sper că managerii IT vor deveni treptat mai conștienți de domeniul managementului cunoștințelor, iar tradiția orală nu va mai servi ca instrument de conservare a cunoștințelor în companie. Studiați-vă standardele de lucru - există o mulțime de lucruri interesante în ele!
Sursa: www.habr.com