Що не кажи, а управління знаннями (Knowledge Management, KM) все ще залишається в середовищі айтішників таким собі дивним звірком: Начебто зрозуміло, що знання - сила (с), але зазвичай під цим розуміються деякі особисті знання, власний досвід, пройдені тренінги, прокачані скелі. Про загальнокорпоративні системи управління знаннями замислюються рідко, мляво, і в основному не розуміють, яку цінність можуть нести знання конкретного розробника в масштабах усієї компанії. Винятки, зрозуміло, є. І той же Олексій Сидорін із КРОК нещодавно давав прекрасне . Але це все ж таки поки що поодинокі явища.
Ось і на Хабрі досі немає хаба, присвяченого управлінню знаннями, тож пишу свій пост у хаб конференцій. Цілком обґрунтовано, якщо що, адже 26 квітня, завдяки ініціативі «Конференцій Олега Буніна», відбулася перша в Росії конференція про управління знаннями в ІТ – .
Мені пощастило попрацювати у Програмному Комітеті конференції, побачити та почути багато такого, що перевернуло певною мірою мій затишний світ менеджера з управління знаннями, і зрозуміти, що ІТ до управління знаннями вже дозріло. Залишилося зрозуміти, з якого боку до нього підступитися.
До речі, 10 та 17-19 квітня пройшли ще дві конференції про управління знаннями: и , на яких мені довелося виступати як експерт. Ухилу в ІТ ці конференції не мали, зате мені є з чим порівнювати. У своєму першому пості хочу поговорити про думки, на які мене, спеціаліста з управління знаннями, наштовхнуло участь у цих конференціях. Можна вважати це як порадами для майбутніх доповідачів, так і для тих, хто причетний до knowledge management за родом діяльності.
У нас було 83 доповіді, 24 слоти та 12 днів для прийняття рішень
83, Карл. Це . Незважаючи на те, що це перша конференція, і централізовано управління знаннями в ІТ мало хто займається, інтерес до теми виявився великий. Дещо ускладнило ситуацію те, що до дедлайну подачі заявок 13 слотів із 24 вже були зайняті, а доповідачі, ймовірно, вважали, що з дедлайном все найцікавіше тільки починається, тому в останні пару днів насипали нам майже половину заявок. Зрозуміло, за 12 днів до фіналізації програми якісно попрацювати з кожним потенційним доповідачем було нереально, тому є ймовірність, що якісь цікаві доповіді опинилися за бортом через нецікаво складені тези. Проте вважаю, що до програми потрапили сильні, глибокі і, головне, прикладні доповіді з великою кількістю подробиць та практик.
І все ж таки хочеться зробити певні висновки з аналізу всіх поданих заявок. Можливо, вони виявляться корисними для когось із читачів, дадуть нове розуміння управління знаннями. Все, що я писатиму далі, це чиста вода імхо, заснована на шестирічному досвіді побудови системи управління знаннями в «Лабораторії Касперського» та спілкуванні з професіоналами в галузі КМ.
Що таке знання?
На молодіжній конференції кожен доповідач, чи то методолог, професор вузу чи спікер, який безпосередньо відповідає у своїй компанії за управління знаннями, починав із запитання «А що таке знання, якими ми збираємося керувати?»
Треба сказати, що питання важливе. Як показала практика роботи в ПК KnowledgeConf 2019, багато хто в ІТ сфері вважає, що знання = документація. Тому часто доводиться чути запитання: «Ми ж документуємо код. Навіщо нам ще якась система керування знаннями? Хіба документації недостатньо?
Ні, недостатньо. З усіх визначень, які спікери давали знанням, мені найближче визначення Євгена Вікторова з Газпромнефти: «знання – це досвід, набутий конкретною людиною при вирішенні конкретного завдання». Зверніть увагу, жодної документації. Документ – це інформація, дані. Вони можуть бути використані при вирішенні конкретного завдання, але знання – це досвід застосування цих даних, а не самі дані. Як із поштовими марками: можна купити найдорожчу марку на пошті, але цінність для колекціонера вона набуває лише після того, як на неї поставили штамп про відправку. Можна спробувати ще більше розкрити: документація = "що в коді написано", а знання = "чому це написано саме так, як приймалося це рішення, яку ціль воно вирішує".
Потрібно сказати, що спочатку і серед членів ПК не було єдиної думки щодо документації та знань. Списую цей факт на те, що в ПК дійсно підібралися люди різних сфер діяльності, і до управління знаннями всі були причетні з різних боків. Але ми, зрештою, дійшли спільного знаменника. А ось пояснити доповідачам, чому їхня доповідь про документування коду не підходить для цієї конференції, було часом непростим заняттям.
Навчання vs. Управління знаннями
Теж цікавий аспект. Особливо останніми днями нам подали дуже багато доповідей про навчання. Про те, як навчати софт скілам, хард скілам, коучи і т.д. Так, безумовно, навчання – це знання. Але які? Якщо ми говоримо про зовнішній коучинг чи проходження тренінгів “as is”, хіба це входить у поняття корпоративного управління знаннями? Ми беремо експертизу ззовні та прикладаємо її там, де «болить». Так, конкретні люди набули нового досвіду (=знання), але в масштабах компанії нічого не сталося.
Ось якщо після проходження навчання співробітник прийшов до офісу і провів аналогічний майстер-клас для колег (пошарив знання) або переніс свої враження та ключові ідеї, які почерпнув, до якоїсь умовної внутрішньої бази знань – це вже управління знаннями. Ось тільки про цю зв'язку зазвичай не думають (або не кажуть).
Якщо взяти особистий досвід, у нас у відділі прийнято після конференції описувати у спеціальному розділі внутрішнього порталу враження, keynotes, ідеї, перераховувати рекомендовані книги тощо. Це той випадок, коли протиставлення між поняттями немає. Управління знаннями, у разі, — це природне продовження зовнішнього навчання.
Ось якби колеги, які подавалися з доповідями про коучинг, розповіли б, наприклад, про те, як вони у своїй тренерській спільноті діляться практиками та які плоди це приносить, це було б, безумовно, про КМ.
Або візьмемо з іншого боку. Були й доповіді про те, як у компанії створили основу знань. Крапка. Закінчена думка.
Але ж творили навіщось? Зібрані знання мають працювати? Поза айтішною тусовкою, яка все ж таки прикладніша і практичніша, часто стикаюся з тією історією, що виконавці проекту з управління знаннями вважають, ніби достатньо закупити софт, наповнити його матеріалами, і всі самі підуть туди користуватися при необхідності. А потім дивуються, що якось не злітає КМ. І такі доповідачі також були.
На мій погляд, ми акумулюємо знання, щоб на їх основі хтось міг навчитися і не зробити якихось помилок. Внутрішнє навчання – це природне продовження системи управління знаннями. Взяти той же онбординг чи наставництво в командах: адже наставники ж діляться внутрішньою інформацією, щоб співробітник швидше влився в команду та процеси. А якщо ми маємо внутрішню базу знань, де вся ця інформація лежить? Хіба це не привід розвантажити наставника та прискорити онбординг? Тим більше, знання будуть доступні 24/7, а не коли у тимліда з'явиться час. І якщо в компанії приходять до цієї думки, протиставлення між термінами також можна прибирати.
У своїй практиці я й займаюся цим: акумулюю знання, а потім, на базі зібраних матеріалів, роблю навчальні курси різного ступеня деталізації для колег з різних підрозділів. А якщо до системи управління знаннями прикрутити ще якийсь модуль для створення тестів, щоб контролювати обізнаність та скіли співробітників, то взагалі виходить ідеальна картинка того самого корпоративного knowledge sharing: одні поділилися інформацією, інші її обробили, упаковали та розшарили для цільових груп, а Потім проконтролювали засвоєння матеріалів.
Маркетинг vs. Практика
Момент теж цікавий. Часто, якщо управлінням знаннями займається призначений співробітник співробітник (HR, L&D), його великим завданням є продаж ідеї КМ співробітникам компанії, створення цінності. Продавати ідею доводиться всім. Але якщо управлінням знаннями займається людина, яка вирішує цим інструментом свій особистий біль, а не виконує завдання керівництва, він зазвичай зберігає фокус на прикладних аспектах проекту. А у співробітника з розвитку персоналу часто відбувається певна профдеформація: він бачить, як це продати, але не дуже уявляє, чому воно саме так влаштоване. І на конференцію подається доповідь, яка є півгодинним суто маркетинговим виступом, про те, які плюшки приносить система, і не містить ні слова про те, як вона влаштована. Але ж саме це і є найцікавіше та важливіше! Як влаштована? Чому так? Які інкарнації вона пережила і що не влаштовувало у минулих реалізаціях?
Якщо створити продукту гарну обгортку, його можна на короткий час забезпечити користувачами. Але інтерес швидко згасне. Якщо виконавець проекту управління знаннями не розуміє його «м'яса», мислить цифрами і метриками, а чи не реальними проблемами цільової аудиторії, то спад настане дуже швидко.
Приходячи на конференцію з такою доповіддю, подібною до рекламного проспекту, треба розуміти, що це буде нецікаво «зовні» вашої компанії. Люди, які прийшли вас послухати, вже купили ідею (вони взагалі чималі гроші заплатили за участь!). Їх не треба переконувати, що потрібно займатися КМ. Їм треба розповісти, як треба та як не треба це робити, і чому. Це не ваш топ-менеджмент, від аудиторії у залі не залежить ваш бонус.
Проте це також дві частини одного проекту, і без хорошого промоції всередині компанії навіть найкрутіший контент залишиться yet another one Sharepoint. І ось якщо розповісти як ви продаєте ідею КМ колегам, які фішки заходять, а які ні, і чому, то розповідь буде дуже цінною.
Але можлива й інша крайність: ми робили круту базу, використовували такі передові практики, але щось співробітники не стали туди ходити. Тому ми в ідеї розчарувалися та перестали цим займатися. Такі заявки також мали. Чому працівники не підтримали? Можливо, їм реально ця інформація виявилася непотрібною (це проблема вивчення цільової аудиторії, про неї треба писати окрему посаду). А може, їм просто погано спілкувалися? А як це взагалі робили? Менеджер управління знаннями – це, у тому числі, і добрий піарник. І якщо він вміє дотримуватися балансу між промоушном і корисністю контенту, то має великі шанси на успіх. Не можна говорити про одне, забуваючи про інше.
цифри
Та й насамкінець про цифри. У пам'ятці речника однієї з конференцій (не KnowledgeConf!) прочитав, що аудиторія любить ексклюзивну інформацію – цифри. Але навіщо? Перед тією конференцією я надовго задумався, чим можуть бути корисні аудиторії мої цифри? Як колегам допоможе, що я зумів за рахунок керування знаннями покращити якийсь показник продуктивності співробітників на N%? Що мої слухачі завтра зроблять інакше, якщо дізнаються про мої цифри? Я вигадав лише один аргумент: «Мені сподобалася одна ваша практика, я хочу впровадити її у себе, але мені треба продати ідею керівнику. Завтра я скажу йому, що в компанії Х вона призвела до такого зростання показників, щоб він «купив» цю ідею». Але ж далеко не всі мої показники ефективності застосовні до будь-якого іншого бізнесу. Можливо, ви можете запропонувати ще якісь аргументи на користь цифр у доповідях? Але на мій погляд, витрачати 10 хвилин доповіді з 30 на цифри, коли можна було б витратити їх на практичні приклади або навіть невеликий воркшоп з аудиторією, імхо, так собі ідея.
І нам також подавали доповіді повні цифр. Після першого обговорення ми просили доповідачів розповісти про практики, які привели до таких результатів. У тих, хто, зрештою, пройшов у фінальну програму, доповіді відрізнялися від вихідного варіанту приблизно повністю. В результаті ми почули вже дуже багато відгуків на тему величезної практичної бази, яку дала конференція. І ніхто поки що не сказав, що «як було цікаво дізнатися, скільки заощадила за рахунок управління знаннями компанія Х».
Завершуючи цей лонгрід, хочу ще раз порадіти, що айтішний світ усвідомив для себе важливість управління знаннями і, сподіваюся, найближчим часом почне активно його реалізовувати, оптимізувати та тюнити під себе. А на Хабрі з'явиться окремий хаб, присвячений управлінню знаннями, і всі наші доповідачі ділитимуться там знаннями з колегами. А поки що можна нишпорити практики в месенджерах, фейсбуках та інших доступних засобах комунікації. Всім лише корисних доповідей та успішних виступів!
Джерело: habr.com