Что ни говори, а управление знаниями (Knowledge Management, KM) все еще остается в среде айтишников этаким диковинным зверьком: Вроде бы понятно, что знание – сила (с), но обычно под этим понимаются некие личные знания, собственный опыт, пройденные тренинги, прокачанные скилы. Про общекорпоративные системы управления знаниями задумываются редко, вяло, и, в основном, не понимают, какую ценность могут нести знания конкретного разработчика в масштабах всей компании. Исключения, разумеется, есть. И тот же Алексей Сидорин из КРОК недавно давал прекрасное интервью. Но это все же пока единичные явления.
Вот и на Хабре до сих пор нет хаба, посвященного управлению знаниями, так что пишу свой пост в хаб конференций. Вполне обоснованно, если что, ведь 26 апреля, благодаря инициативе «Конференций Олега Бунина», состоялась первая в России конференция про управление знаниями в ИТ – KnowledgeConf 2019.
Мне посчастливилось поработать в Программном Комитете конференции, увидеть и услышать много такого, что перевернуло в какой-то мере мой уютный мирок менеджера по управлению знаниями, и понять, что ИТ до управления знаниями уже дозрело. Осталось понять, с какой стороны к нему подступиться.
Кстати, 10 и 17-19 апреля прошли еще две конференции про управление знаниями: Quorum CEDUCA и II молодежная конференция KMconf’19, на которых мне довелось выступать в качестве эксперта. Уклона в ИТ эти конференции не имели, но зато мне есть с чем сравнивать. В своем первом посте хочу поговорить о мыслях, на которые меня, специалиста управления знаниями, натолкнуло участие в этих конференциях. Можно считать это как советами для будущих докладчиков, так и для причастных к knowledge management по роду деятельности.
83, Карл. Это не шутки. Несмотря на то, что это первая конференция, и централизованно управлением знаниями в ИТ мало кто занимается, интерес к теме оказался велик. Несколько осложнило ситуацию то, что к дедлайну подачи заявок 13 слотов из 24 уже были заняты, а докладчики, вероятно, считали, что с дедлайном все самое интересное только начинается, поэтому в последние пару дней насыпали нам едва ли не половину заявок. Разумеется, за 12 дней до финализации программы качественно поработать с каждым потенциальным докладчиком было нереально, поэтому, есть вероятность, что какие-то интересные доклады оказались за бортом из-за неинтересно составленных тезисов. И тем не менее, считаю, что в программу попали сильные, глубокие и, главное, прикладные доклады с большим количеством подробностей и практик.
И все же хочется сделать определенные выводы из анализа всех поданных заявок. Возможно, они окажутся полезными кому-то из читателей, дадут новое понимание управления знаниями. Все, что я буду писать дальше, это чистейшей воды имхо, основанное на шестилетнем опыте построения системы управления знаниями в «Лаборатории Касперского» и общении с профессионалами в области КМ.
На молодежной конференции каждый докладчик, будь то методолог, профессор вуза или спикер, непосредственно отвечающий в своей компании за управление знаниями, начинал с вопроса «А что такое знания, которыми мы собираемся управлять?»
Надо сказать, что вопрос важный. Как показала практика работы в ПК KnowledgeConf 2019, многие в ИТ сфере считают, что знания = документация. Поэтому часто приходится слышать вопрос: «Мы же и так документируем код. Зачем нам еще какая-то система управления знаниями? Разве документации недостаточно?»
Нет, недостаточно. Из всех определений, которые спикеры давали знаниям, мне ближе всего определение Евгения Викторова из Газпромнефти: «знание – это опыт, полученный конкретным человеком при решении конкретной задачи». Обратите внимание, никакой документации. Документ – это информация, данные. Они могут быть использованы при решении конкретной задачи, но знания – это опыт по применению этих данных, а не сами данные. Как с почтовыми марками: можно купить самую дорогую марку на почте, но ценность для коллекционера она приобретает только после того, как на нее поставили штамп об отправке. Можно попробовать еще больше раскрыть: документация = «что в коде написано», а знания = «почему это написано именно так, как принималось это решение, какую цель оно решает».
Надо сказать, что изначально и среди членов ПК не было единого мнения насчет документации и знаний. Списываю этот факт на то, что в ПК действительно подобрались люди самых разных сфер деятельности, и к управлению знаниями все были причастны с разных сторон. Но мы, в итоге, пришли к общему знаменателю. А вот объяснить докладчикам, почему их доклад про документирование кода не подходит для данной конференции, было, порой, непростым занятием.
Тоже интересный аспект. Особенно в последние дни нам подали очень много докладов про обучение. Про то, как обучать софт скилам, хард скилам, коучить и т.д. Да, безусловно, обучение – это про знания. Но какие? Если мы говорим про внешний коучинг или прохождение тренингов “as is”, разве это входит в понятие корпоративного управления знаниями? Мы берем экспертизу извне и прикладываем ее там, где «болит». Да, конкретные люди приобрели новый опыт (=знания), но в масштабах компании ничего не произошло.
Вот если после прохождения обучения сотрудник пришел в офис и провел аналогичный мастер-класс для коллег (пошарил знания) или перенес свои впечатления и ключевые идеи, которые почерпнул, в некую условную внутреннюю базу знаний – это уже управление знаниями. Вот только про эту связку обычно не думают (или не говорят).
Если взять личный опыт, у нас в отделе принято после конференции описывать в специальном разделе внутреннего портала впечатления, keynotes, идеи, перечислять рекомендованные книги и т.д. Это тот случай, когда противопоставления между понятиями нет. Управление знаниями, в данном случае, — это естественное продолжение внешнего обучения.
Вот если бы коллеги, которые подавались с докладами про коучинг, рассказали бы, например, о том, как они в своем тренерском сообществе делятся практиками и какие плоды это приносит, это было бы, безусловно про КМ.
Или возьмем с другой стороны. Были и доклады о том, как в компании создали базу знаний. Точка. Законченная мысль.
Но ведь создавали же зачем-то? Собранные знания же должны работать? Вне айтишной тусовки, которая все же более прикладная и практичная, часто сталкиваюсь с той историей, что исполнители проекта по управлению знаниями считают, будто достаточно закупить софт, наполнить его материалами, и все сами пойдут туда пользоваться при необходимости. А потом удивляются, что как-то не взлетает КМ. И такие докладчики тоже были.
На мой взгляд, мы аккумулируем знания, чтобы на их основе кто-то чему-то мог научиться и не сделать каких-то ошибок. Внутреннее обучение – это естественное продолжение системы управления знаниями. Взять тот же онбординг или наставничество в командах: ведь наставники же делятся внутренней информацией, чтобы сотрудник быстрее влился в команду и процессы. А если у нас есть внутренняя база знаний, где вся эта информация лежит? Разве это не повод разгрузить наставника и ускорить онбординг? Тем более, знания будут доступны 24/7, а не когда время у тимлида появится. И если в компании приходят к этой мысли, противопоставление между терминами тоже можно убирать.
В своей практике я как раз и занимаюсь этим: аккумулирую знания, а потом, на базе собранных материалов, делаю обучающие курсы разной степени детализации для коллег из разных подразделений. А если к системе управления знаниями прикрутить еще какой-нибудь модуль для создания тестов, чтобы контролировать осведомленность и скилы сотрудников, то вообще получается идеальная картинка того самого корпоративного knowledge sharing: одни поделились информацией, другие ее обработали, упаковали и расшарили для целевых групп, а потом проконтролировали усвоение материалов.
Момент тоже интересный. Часто, если управлением знаниями занимается назначенный сотрудник сотрудник (HR, L&D), то его большой задачей является продажа идеи КМ сотрудникам компании, создание ценности. Продавать идею приходится всем. Но если управлением знаниями занимается человек, который решает этим инструментом свою личную боль, а не выполняет задачу руководства, то он обычно сохраняет фокус на прикладных аспектах проекта. А у сотрудника из развития персонала часто происходит определенная профдеформация: он видит, как это продать, но не очень представляет, почему оно именно так устроено. И на конференцию подается доклад, который представляет собой получасовое чисто маркетинговое выступление, о том, какие плюшки приносит система, и не содержит ни слова о том, как она устроена. Но ведь именно это и есть самое интересное и важное! Как устроена? Почему именно так? Какие инкарнации она пережила, и что не устраивало в прошлых реализациях?
Если создать продукту красивую обертку, то его можно на короткое время обеспечить пользователями. Но интерес быстро угаснет. Если исполнитель проекта по управлению знаниями не понимает его «мяса», мыслит цифрами и метриками, а не реальными проблемами целевой аудитории, то спад наступит очень быстро.
Приходя на конференцию с таким докладом, похожим на рекламный проспект, надо понимать, что это будет неинтересно «снаружи» вашей компании. Люди, пришедшие вас послушать, уже купили идею (они вообще-то немалые деньги заплатили за участие!). Их не надо убеждать, что нужно в принципе заниматься КМ. Им надо рассказать, как надо и как не надо это делать, и почему. Это не ваш топ-менеджмент, от аудитории в зале не зависит ваш бонус.
И тем не менее, это также две части одного проекта, и без хорошего промоушна внутри компании даже самый крутой контент останется yet another one Sharepoint. И вот если рассказать как вы продаете идею КМ коллегам, какие фишки заходят, а какие нет, и почему, то рассказ будет очень и очень ценным.
Но возможна и другая крайность: мы делали крутейшую базу, использовали вот такие передовые практики, но что-то сотрудники не стали туда ходить. Поэтому мы в идее разочаровались и перестали этим заниматься. Такие заявки тоже у нас были. Почему сотрудники не поддержали? Возможно, им реально эта информация оказалась не нужна (это проблема изучения целевой аудитории, про нее надо писать отдельный пост). А может быть, им просто плохо коммуницировали? А как вообще это делали? Менеджер управления знаниями – это, в том числе, и хороший пиарщик. И если он умеет соблюдать баланс между промоушном и полезностью контента, то у него большие шансы на успех. Нельзя говорить об одном, забывая о другом.
Ну и напоследок про цифры. В памятке спикера одной из конференций (не KnowledgeConf!) прочитал, что аудитория любит эксклюзивную информацию – цифры. Но зачем? Перед той конференцией я прямо надолго задумался, чем могут быть полезны аудитории мои цифры? Как коллегам поможет, что я сумел за счет управления знаниями улучшить какой-то показатель производительности сотрудников на N%? Что мои слушатели завтра сделают иначе, если узнают мои цифры? Я придумал только один аргумент: «Мне понравилась одна ваша практика, я хочу внедрить ее у себя, но мне надо продать идею руководителю. Завтра я скажу ему, что в компании Х она привела вот к такому росту показателей, чтобы он «купил» эту идею». Но ведь далеко не все мои показатели эффективности применимы к любому другому бизнесу. Может быть, вы сможете предложить еще какие-то аргументы в пользу цифр в докладах? Но на мой взгляд, тратить 10 минут доклада из 30 на цифры, когда можно было бы потратить их на практические примеры или даже небольшой воркшоп с аудиторией, имхо, так себе идея.
И нам тоже подавали доклады полные цифр. После первого обсуждения мы просили докладчиков рассказать о практиках, которые к таким результатам привели. У тех из них, кто, в итоге, прошел в финальную программу, доклады отличались от исходного варианта примерно полностью. В результате, мы услышали уже очень много отзывов на тему огромной практической базы, которую дала конференция. И никто пока не сказал, что «как было интересно узнать, сколько сэкономила за счет управления знаниями компания Х».
Завершая этот лонгрид, хочу еще раз порадоваться, что айтишный мир осознал для себя важность управления знаниями и, надеюсь, в ближайшее время начнет активно его реализовывать, оптимизировать и тюнить под себя. А на Хабре появится отдельный хаб, посвященный управлению знаниями, и все наши докладчики будут делиться там знаниями с коллегами. А пока можно шарить практики в мессенджерах, фейсбуках и прочих доступных средствах коммуникации. Всем только полезных докладов и успешных выступлений!
Вот и на Хабре до сих пор нет хаба, посвященного управлению знаниями, так что пишу свой пост в хаб конференций. Вполне обоснованно, если что, ведь 26 апреля, благодаря инициативе «Конференций Олега Бунина», состоялась первая в России конференция про управление знаниями в ИТ – KnowledgeConf 2019.
Мне посчастливилось поработать в Программном Комитете конференции, увидеть и услышать много такого, что перевернуло в какой-то мере мой уютный мирок менеджера по управлению знаниями, и понять, что ИТ до управления знаниями уже дозрело. Осталось понять, с какой стороны к нему подступиться.
Кстати, 10 и 17-19 апреля прошли еще две конференции про управление знаниями: Quorum CEDUCA и II молодежная конференция KMconf’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 на цифры, когда можно было бы потратить их на практические примеры или даже небольшой воркшоп с аудиторией, имхо, так себе идея.
И нам тоже подавали доклады полные цифр. После первого обсуждения мы просили докладчиков рассказать о практиках, которые к таким результатам привели. У тех из них, кто, в итоге, прошел в финальную программу, доклады отличались от исходного варианта примерно полностью. В результате, мы услышали уже очень много отзывов на тему огромной практической базы, которую дала конференция. И никто пока не сказал, что «как было интересно узнать, сколько сэкономила за счет управления знаниями компания Х».
Завершая этот лонгрид, хочу еще раз порадоваться, что айтишный мир осознал для себя важность управления знаниями и, надеюсь, в ближайшее время начнет активно его реализовывать, оптимизировать и тюнить под себя. А на Хабре появится отдельный хаб, посвященный управлению знаниями, и все наши докладчики будут делиться там знаниями с коллегами. А пока можно шарить практики в мессенджерах, фейсбуках и прочих доступных средствах коммуникации. Всем только полезных докладов и успешных выступлений!
