Hei alle sammen. Etter et halvt år har gått, og i løpet av denne tiden rakk jeg å snakke på ytterligere to konferanser og holde foredrag om temaet kunnskapsledelse i to store IT-selskaper. Når jeg kommuniserte med kolleger, innså jeg at innen IT er det fortsatt mulig å snakke om kunnskapsstyring på "nybegynnernivå", eller rettere sagt, bare innse at kunnskapsstyring er nødvendig for enhver avdeling i enhver bedrift. I dag vil det være et minimum av min egen erfaring - jeg vil gjerne gjennomgå de eksisterende internasjonale standardene innen kunnskapsledelse.
La oss starte med sannsynligvis det mest populære merket innen standardisering - ISO. Tenk deg at det er en hel egen standard dedikert til kunnskapsstyringssystemer (ISO 30401:2018). Men i dag ville jeg ikke dvele ved det. Før vi forstår «hvordan» et kunnskapsstyringssystem skal se ut og fungere, må vi være enige om at det i prinsippet er nødvendig.
La oss ta for eksempel ISO 9001: 2015 (Kvalitetsstyringssystemer). Som navnet tilsier, er dette en standard dedikert til kvalitetsstyringssystemet. For å bli sertifisert i henhold til denne standarden, må en organisasjon sikre åpenhet og kontinuitet i arbeidsprosesser og produserte produkter og/eller tjenester. Med andre ord betyr et sertifikat at alt i din bedrift fungerer problemfritt, problemfritt, du forstår hvilke risikoer dagens organisering av prosesser medfører, du vet hvordan du kontrollerer disse risikoene, og streber etter å minimere dem.
Hva handler kunnskapsledelse om? Og her er hva:
7.1.6 Organisasjonskunnskap
Organisasjonen skal bestemme kunnskapen som er nødvendig for å drive sine prosesser og for å oppnå samsvar med produkter og tjenester.
Kunnskap skal vedlikeholdes og gjøres tilgjengelig i den grad det er nødvendig.
Når organisasjonen vurderer endrede behov og trender, bør den ta hensyn til sin eksisterende kunnskap og bestemme hvordan den skal skaffe seg eller gi tilgang til tilleggskunnskap og dens oppdatering.
NOTE 1 Organisasjonskunnskap er organisasjonsspesifikk kunnskap; mest basert på erfaring.
Kunnskap er informasjon som brukes og deles for å nå organisatoriske mål.
MERKNAD 2 En organisasjons kunnskapsbase kan være:
a) interne kilder (f.eks. åndsverk; kunnskap fra erfaring; erfaringer fra mislykkede eller vellykkede prosjekter; innsamling og deling av udokumentert kunnskap og erfaring; resultater av prosess-, produkt- og tjenesteforbedringer);
b) eksterne kilder (f.eks. standarder, akademia, konferanser, kunnskap fra kunder og eksterne leverandører).
Og nedenfor, i applikasjoner:
Organisatoriske kunnskapskrav er introdusert for:
a) beskytte organisasjonen mot tap av kunnskap, for eksempel på grunn av:
- personalomsetning;
- umuligheten av å innhente og utveksle informasjon;
b) oppmuntre organisasjonen til å tilegne seg kunnskap, for eksempel gjennom:
- lærer av å gjøre;
- veiledning;
- referansemåling.
Så, ISO-standarden innen kvalitetsstyring sier at for å sikre kvaliteten på virksomheten, må en virksomhet engasjere seg i kunnskapsledelse. Det stemmer, ikke noe alternativ - "må". Ellers avvik, og farvel. Dette faktum alene antyder så å si at dette ikke er et valgfritt aspekt i organisasjonen, ettersom kunnskapsstyring i IT ofte behandles, men en obligatorisk komponent i forretningsprosesser.
I tillegg forteller standarden hvilke risikoer kunnskapsstyring er designet for å eliminere. Faktisk er de ganske åpenbare.
La oss forestille oss ... nei, det er ikke sånn - husk en situasjon fra karrieren din da du virkelig trengte litt informasjon på jobben, og den eneste operatøren var på ferie / forretningsreise i det øyeblikket, sluttet i selskapet eller bare var syk . Husket? Jeg tror nesten alle av oss har opplevd dette. Hva følte du i det øyeblikket?
Dersom ledelsen i enheten etter en tid skal analysere svikten i prosjektfristene, vil den selvsagt finne den skyldige og roe ned på dette. Men i øyeblikket da kunnskap var nødvendig, hjalp det deg ikke personlig å forstå at "RM har skylden, som dro til Bali og ikke la noen instruksjoner i tilfelle spørsmål." Det er klart han har skylden. Men det hjelper deg ikke med å løse problemet.
Hvis kunnskap er dokumentert i et system tilgjengelig for folk som kan trenge den, blir den beskrevne "resort"-historien nesten umulig. Dermed sikres kontinuiteten i forretningsprosessene, noe som betyr at ferier, avganger av ansatte og den svært beryktede bussfaktoren ikke er forferdelig for bedriften - kvaliteten på produktet / tjenesten vil forbli på sitt vanlige nivå.
Hvis en bedrift har en plattform for utveksling og lagring av informasjon og erfaringer, og det har dannet seg en kultur (vane) med å bruke denne plattformen, trenger ikke ansatte å vente flere dager på svar fra en kollega (eller til og med se etter denne kollegaen i flere dager) og sette på grunn av dette for å holde oppgavene dine.
Hvorfor snakker jeg om vane? For det er ikke nok å lage en kunnskapsbase for at folk kan begynne å bruke den. Vi er alle vant til å søke på Google etter svar på spørsmålene våre, og intranettet er oftest knyttet til feriesøknader og oppslagstavle. Vi har ikke for vane å «se etter informasjon om Agile rammeverk» (for eksempel) på intranettet. Derfor, selv om vi har den kuleste kunnskapsbasen på ett sekund, vil ingen begynne å bruke den i neste sekund (og til og med neste måned) - det er ingen vane. Å endre vanene dine er smertefullt og tidkrevende. Ikke alle er klare for dette. Spesielt hvis i 15 år "og de jobbet på samme måte." Men uten dette vil selskapets kunnskapssatsing mislykkes. Det er derfor mestere i KM uløselig kobler kunnskapsledelse med endringsledelse.
Det er også verdt å ta hensyn til det faktum at "Når man vurderer endrede behov og trender, må en organisasjon ta hensyn til sin eksisterende kunnskap ...", dvs. utvikle en kultur for å referere til tidligere erfaring når du tar beslutninger i en verden i endring. Og merk igjen "må".
Denne lille paragrafen i standarden sier forresten mye om erfaring. Vanligvis, når det gjelder kunnskapshåndtering, begynner stereotypier å gli et bilde av en kunnskapsbase med hundrevis av dokumenter plassert i form av filer (forskrifter, krav). Men ISO snakker om erfaring. Kunnskapen oppnådd fra tidligere erfaring fra selskapet og hver av dets ansatte er det som lar deg unngå risikoen for å gjenta feil, umiddelbart ta bedre beslutninger og til og med lage et nytt produkt. I de mest modne selskapene innen kunnskapsledelse (inkludert russiske, forresten) blir kunnskapsledelse sett på som et middel til å øke selskapets kapitalisering, skape nye produkter, utvikle nye ideer og optimalisere prosesser. Det er ikke en kunnskapsbase, det er en mekanisme for innovasjon. Det hjelper oss å forstå dette mer detaljert. PMI PMBOK retningslinjer.
PMB OK er en veiledning til prosjektledelsens kunnskapsorgan, PMa-håndboken. Den sjette utgaven (2016) av denne veiledningen introduserer en del om prosjektintegrasjonsledelse, som igjen inkluderer en del om prosjektkunnskapsledelse. Dette elementet ble opprettet "basert på kommentarer fra brukere av manualen", dvs. har blitt et produkt av erfaring med å bruke tidligere versjoner av veiledningen under reelle forhold. Og virkeligheten krevde kunnskapsledelse!
Hovedutgangen til det nye elementet er "Lessons Learned Register" (i ISO-standarden beskrevet ovenfor, er det forresten også nevnt). Videre, i henhold til retningslinjene, bør sammenstillingen av dette registeret utføres gjennom hele gjennomføringen av prosjektet, og ikke ved avslutningen, når det er på tide å analysere resultatet. Etter min mening er dette veldig likt retrospektiv i agile, men jeg skal skrive et eget innlegg om dette. Bokstavelig talt høres teksten i PMBOK slik ut:
Prosjektkunnskapsledelse er prosessen med å bruke eksisterende kunnskap og skape ny kunnskap for å nå prosjektmål og fremme læring i organisasjonen.
Kunnskapsområdet prosjektintegrasjonsledelse krever integrering av resultatene oppnådd i alle andre kunnskapsområder.
Nye trender i integrasjonsprosesser inkluderer blant annet:
...
• Prosjektkunnskapsledelse
Arbeidsstyrkens stadig mer mobile og skiftende natur krever også en mer streng prosess med å fange kunnskap gjennom hele livssyklusen til et prosjekt og overføre den til målgrupper på en måte som forhindrer tap av kunnskap.
***
De viktigste fordelene med denne prosessen er at den tidligere ervervede kunnskapen om organisasjonen brukes til å oppnå eller forbedre resultatene av prosjektet, og kunnskapen som oppnås under gjennomføringen av det nåværende prosjektet forblir tilgjengelig for å støtte organisasjonens drift og fremtidige prosjekter eller deres faser. Denne prosessen gjennomføres gjennom hele prosjektet.
Jeg vil ikke kopiere og lime inn hele den store delen av manualen her. Du kan lese den selv og trekke passende konklusjoner. Sitatene ovenfor er nok etter min mening. Det virker for meg at tilstedeværelsen av en slik spesifikasjon av oppgaven til RM for prosjektkunnskapsledelse allerede taler om viktigheten av dette aspektet når du arbeider med prosjekter. Forresten, jeg hører ofte oppgaven: "Hvem trenger vår kunnskap i andre avdelinger?" Det vil si, hvem trenger disse erfaringene?
Faktisk ser man ofte at en enhet ser på seg selv som en "enhet i et vakuum". Her er vi med biblioteket vårt, men det er resten av selskapet, og kunnskap om biblioteket vårt vil ikke være nyttig for henne på noen måte. Om biblioteket - kanskje. Hva med relaterte prosesser?
Et banalt eksempel: i løpet av arbeidet med et prosjekt var det samhandling med en entreprenør. For eksempel med en designer. Entreprenøren viste seg å være så som så, bommet på fristene, nektet å sluttføre uten tilleggsbetaling. RM registrert i registeret over erfaringer at det ikke er verdt å jobbe med denne upålitelige entreprenøren. Samtidig søkte de et sted i markedsføringen etter en designer og kom over samme entreprenør. Og på dette tidspunktet er det to alternativer:
a) Hvis selskapet har en god kultur for gjenbruk av erfaring, vil en markedsføringskollega se i leksjonsregisteret om noen allerede har kontaktet denne entreprenøren, se negative tilbakemeldinger fra vår PM og vil ikke kaste bort tid og penger på å kommunisere med denne upålitelige entreprenøren .
b) hvis selskapet ikke har en slik kultur, vil markedsføreren henvende seg til den samme upålitelige entreprenøren, tape selskapets penger, tid, og kan for eksempel forstyrre en viktig og presserende kampanje.
Hvilket alternativ virker mer vellykket? Og merk at det ikke var informasjon om produktet under utvikling som var nyttig, men om de medfølgende utviklingsprosessene. Og det viste seg å være nyttig ikke for en annen RM, men for en ansatt i en helt annen retning. Derav konklusjonen: det er umulig å vurdere utvikling separat fra salg, teknisk støtte fra business intelligence og IT fra ACS. Alle i bedriften har arbeidserfaring som vil vise seg nyttig for noen andre i bedriften. Og det er slett ikke nødvendig at de skal være representanter for beslektede områder.
Den tekniske siden av prosjektet kan imidlertid komme godt med. Prøv å revidere prosjekter i din bedrift de siste årene. Du vil bli overrasket over hvor mange sykler som har blitt oppfunnet for lignende problemer. Hvorfor? Fordi kunnskapsdelingsprosesser ikke er etablert.
Så kunnskapsstyring, ifølge PMI-manualen, er en av oppgavene til PM. Som du kan se, inkluderer to kjente organisasjoner som utfører betalte sertifiseringer i henhold til deres standarder kunnskapsstyring i listen over må-ha-verktøy for kvalitetskontroll og prosjektarbeid. Hvorfor tror ledere i IT-bedrifter fortsatt at kunnskapsledelse er dokumentasjon? Hvorfor forblir kjøleren og røykerommet sentrene for kunnskapsutveksling? Det handler om forståelse og vaner. Jeg håper at forståelsen av feltet kunnskapsledelse etter hvert vil bli mer og mer blant IT-ledere, og den muntlige tradisjonen vil slutte å fungere som et verktøy for å bevare kunnskap i bedriften. Studer standardene for arbeidet ditt - de har mange interessante ting!
Kilde: www.habr.com