"Скорость поиска, количество поисковых запросов, удовлетворенность "нашли, что искали", объем UCG, количество экспертов а карте экспертов, активность и интенсивность взаимодействия с ними, Сокращение трудозатрат на формализацию и загрузку знаний.
Сокращение потери от ухода сотрудников, скорость адаптации новых сотрудников, снижение количества ошибок, снижение затрат на обучение за счет переиспользования знаний Повышение качества и эффективности проектной деятельности (выученные уроки, лучшие практики), увеличение скорости реализации проектов. Выгоды от инновационных решений NPS системы управления знаниям в целом, как следствие динамика лояльности сотрудника к компании.
Естественно, метрики появлялись и ростом зрелости системы и закреплением в ней конкретных инструментов. Начинали с примитивных количественных показателей цифровой системы - посещаемость, просмотры, оценки, возвраты, количественные метрики по наполнению системы знаниями".
"C утверждением - Sharepoint это РСУБД для непрограммистов - согласна. Но отвечая на вопрос, я бы сказала, что мы ведем речь все же о массовом корпоративном пользователе, который читает текст и пишет текст в процессе своей работы.
Даже такой формат обмена знаниями требует усилий и мотивации. Использование разметки и, тем более SQL, - это точно инструмент в руках команды, которая создает систему управления знаниями. Каждый решает свои задачи".
Годный, почему нет. Просто сейчас выбор методов больше. Можно сразу базу знаний современную завести. TEAMLY, к примеру. Есть бесплатная версия, есть платная.
Да, блоги. В 2012-м году - вполне адекватное решение для начала внедрения управления знаниями в огромной структуре. В целом, согласен, внедрение процесса управления знаниями - это череда четких и последовательных действий, как и при любом бизнес-процессе. Мы тоже начинали с блогов на корпортале, потому что это был рабочий метод тогда.
Хороший вопрос, спасибо! У нас тоже ведение бз было рабочей зоной отчуждения. Поэтому внедрили 2 подхода: статьи пишут менеджеры проектов, руководители отделов, тимлиды - эти статьи обстоятельные, т.к они всю полезность для себя и своей команды понимают. 2 подход: разработчики со своей стороны тоже все, что можно пишут и описывают в бз (проблемы, решения, какие-то отчеты и тд), потому что руководитель иначе не примет работу. Конечно, система еще не на 100% идеальна, но основной массив знаний по продуктами и проектам оседает в бз. База знаний у нас своя, поэтому функционал релизим сначала у себя, пробуем на всех отделах, потом дорабатываем по отзывам, ловим баги и тд. Надо делать так, чтобы ведение бз занимало у человека как можно меньше лишних телодвижений. На эту тему есть статья от руководителя команды разработки Как мы внедрили свою же базу знаний в команду разработки базы знаний: какую придумали структуру, шаблоны и инструменты / Хабр (habr.com)
Спасибо за комментарий. А под системой управления знаниями вы только софт имеете в виду? Просто хочу уточнить: "система управления знаниями" - это сам по себе софт, или "система управления знаниями" - это весь процесс циркуляции информации, включая бизнес-цели, привычки, слабые и сильные места, где теряется информация или наоборот сильная экспертиза. Во-втором случае софт, это средство, а не самоцель.
Нам это важно понимать вообще для всех статей: смогли мы это объяснить, или может людям наоборот интереснее технические характеристики софта?
Нет, пока человеческим. Решил порассуждать на тему глобальной цифровизации в области управления знаниями. Не за горами тот день, когда ИИ напишет статью на Хабр, которая понравится всем. Но этот будет уже не то - не подискутировать.
Да, на самом деле это одна из ключевых задач. Когда ты ищешь ту или иную тему, то находишь несколько статей. Видно, что это опыт конкретных людей и проектов. По дате добавления можно сопоставить для себя, какой опыт более релевантный. Что касается каких-то регламентов и инструментария, то за этим у нас следят отдельные соответствующие подразделения и люди, которые поддерживают процессы и развивают инструментарий.
Тут смотря с какой стороны подойти. Например, приходит к тебе подчиненный и спрашивает: "Тут такая проблема. Как решать?". А я-то помню, что месяц назад мы уже такой кейс с другой командой решили. Я-то знаю как, а он нет. И вместо того, чтобы копаться в своей памяти, можно один раз написать в блог и кидать всем ссылку. Ну и если записал в блог например, самому потом проще вспомнить, что там именно за решение было. "Некогда" - это правда проблема, но тут вопрос философский: какая разница сейчас потратить время или потом на объяснение одного и того же?
Это да, поэтому нужен человек, который задавал бы редполитику и следил за ней
Вы абсолютно правы. Обязательно в такой ситуации, особенно на старте выстраивания процессов и системы УЗ должен быть драйвер. Заинтересованное лицо, так сказать. Также в команде может быть так называемый knowledge manager, который и помогает выстраивать весь процесс. Я обязательно затрону эту тему чуть дальше.
Спасибо за обратную связь! Согласен, я тоже считаю, что тема управления знаниями интересная и нужная. Поэтому решил поделиться своим опытом и начал с самых истоков. Это была вводная статья, чтобы сделать заход в тему. А в следующих статьях я уже дам конкретные инструменты и раскрою её подробнее.
Очень круто, что вы подняли эту тему, спасибо! Я как раз собирался рассказать в следующих статьях, как реально наладить управление знаниями, чтобы они передавались не только по сарафанке внутри отдела. На том этапе развития компании делиться разными знаниями в блогах было вполне приемлемо и даже прогрессивно. Это сейчас для управления знаниями появилось специальное ПО и культура изменилась. Но есть один момент: те примеры, которые вы приводите, не совсем про управление знаниями. Про админов - это вопрос распределения задач и бизнес-процессов. А про начальника - это вопрос о том, можно ли высказывать свое мнение, и в какой форме.
Цитирую ответ от Ольги:
"Скорость поиска, количество поисковых запросов, удовлетворенность "нашли, что искали", объем UCG, количество экспертов а карте экспертов, активность и интенсивность взаимодействия с ними, Сокращение трудозатрат на формализацию и загрузку знаний.
Сокращение потери от ухода сотрудников, скорость адаптации новых сотрудников, снижение количества ошибок, снижение затрат на обучение за счет переиспользования знаний Повышение качества и эффективности проектной деятельности (выученные уроки, лучшие практики), увеличение скорости реализации проектов. Выгоды от инновационных решений NPS системы управления знаниям в целом, как следствие динамика лояльности сотрудника к компании.
Естественно, метрики появлялись и ростом зрелости системы и закреплением в ней конкретных инструментов. Начинали с примитивных количественных показателей цифровой системы - посещаемость, просмотры, оценки, возвраты, количественные метрики по наполнению системы знаниями".
Задал ваш вопрос Ольге. Цитирую ответ:
"C утверждением - Sharepoint это РСУБД для непрограммистов - согласна. Но отвечая на вопрос, я бы сказала, что мы ведем речь все же о массовом корпоративном пользователе, который читает текст и пишет текст в процессе своей работы.
Даже такой формат обмена знаниями требует усилий и мотивации. Использование разметки и, тем более SQL, - это точно инструмент в руках команды, которая создает систему управления знаниями. Каждый решает свои задачи".
Годный, почему нет. Просто сейчас выбор методов больше. Можно сразу базу знаний современную завести. TEAMLY, к примеру. Есть бесплатная версия, есть платная.
Да, блоги. В 2012-м году - вполне адекватное решение для начала внедрения управления знаниями в огромной структуре. В целом, согласен, внедрение процесса управления знаниями - это череда четких и последовательных действий, как и при любом бизнес-процессе. Мы тоже начинали с блогов на корпортале, потому что это был рабочий метод тогда.
Хороший вопрос, спасибо! У нас тоже ведение бз было рабочей зоной отчуждения. Поэтому внедрили 2 подхода: статьи пишут менеджеры проектов, руководители отделов, тимлиды - эти статьи обстоятельные, т.к они всю полезность для себя и своей команды понимают. 2 подход: разработчики со своей стороны тоже все, что можно пишут и описывают в бз (проблемы, решения, какие-то отчеты и тд), потому что руководитель иначе не примет работу. Конечно, система еще не на 100% идеальна, но основной массив знаний по продуктами и проектам оседает в бз. База знаний у нас своя, поэтому функционал релизим сначала у себя, пробуем на всех отделах, потом дорабатываем по отзывам, ловим баги и тд. Надо делать так, чтобы ведение бз занимало у человека как можно меньше лишних телодвижений. На эту тему есть статья от руководителя команды разработки Как мы внедрили свою же базу знаний в команду разработки базы знаний: какую придумали структуру, шаблоны и инструменты / Хабр (habr.com)
Спасибо за комментарий. А под системой управления знаниями вы только софт имеете в виду? Просто хочу уточнить: "система управления знаниями" - это сам по себе софт, или "система управления знаниями" - это весь процесс циркуляции информации, включая бизнес-цели, привычки, слабые и сильные места, где теряется информация или наоборот сильная экспертиза. Во-втором случае софт, это средство, а не самоцель.
Нам это важно понимать вообще для всех статей: смогли мы это объяснить, или может людям наоборот интереснее технические характеристики софта?
Нет, пока человеческим. Решил порассуждать на тему глобальной цифровизации в области управления знаниями. Не за горами тот день, когда ИИ напишет статью на Хабр, которая понравится всем. Но этот будет уже не то - не подискутировать.
Да, на самом деле это одна из ключевых задач.
Когда ты ищешь ту или иную тему, то находишь несколько статей. Видно, что это опыт конкретных людей и проектов. По дате добавления можно сопоставить для себя, какой опыт более релевантный.
Что касается каких-то регламентов и инструментария, то за этим у нас следят отдельные соответствующие подразделения и люди, которые поддерживают процессы и развивают инструментарий.
Тут смотря с какой стороны подойти. Например, приходит к тебе подчиненный и спрашивает: "Тут такая проблема. Как решать?". А я-то помню, что месяц назад мы уже такой кейс с другой командой решили. Я-то знаю как, а он нет. И вместо того, чтобы копаться в своей памяти, можно один раз написать в блог и кидать всем ссылку. Ну и если записал в блог например, самому потом проще вспомнить, что там именно за решение было. "Некогда" - это правда проблема, но тут вопрос философский: какая разница сейчас потратить время или потом на объяснение одного и того же?
Это да, поэтому нужен человек, который задавал бы редполитику и следил за ней
Вы абсолютно правы. Обязательно в такой ситуации, особенно на старте выстраивания процессов и системы УЗ должен быть драйвер. Заинтересованное лицо, так сказать.
Также в команде может быть так называемый knowledge manager, который и помогает выстраивать весь процесс.
Я обязательно затрону эту тему чуть дальше.
Спасибо за обратную связь! Согласен, я тоже считаю, что тема управления знаниями интересная и нужная. Поэтому решил поделиться своим опытом и начал с самых истоков. Это была вводная статья, чтобы сделать заход в тему.
А в следующих статьях я уже дам конкретные инструменты и раскрою её подробнее.
Очень круто, что вы подняли эту тему, спасибо! Я как раз собирался рассказать в следующих статьях, как реально наладить управление знаниями, чтобы они передавались не только по сарафанке внутри отдела. На том этапе развития компании делиться разными знаниями в блогах было вполне приемлемо и даже прогрессивно. Это сейчас для управления знаниями появилось специальное ПО и культура изменилась.
Но есть один момент: те примеры, которые вы приводите, не совсем про управление знаниями. Про админов - это вопрос распределения задач и бизнес-процессов. А про начальника - это вопрос о том, можно ли высказывать свое мнение, и в какой форме.