Всем привет. После ЗнанияКонф 2019 Прошло полгода, за это время я успел выступить еще на двух конференциях и прочитать лекции на тему управления знаниями в двух крупных ИТ-компаниях.
Общаясь с коллегами, я понял, что в ИТ еще можно говорить об управлении знаниями на уровне «новичок», а точнее просто осознавать, что управление знаниями необходимо любому отделу любой компании.
Сегодня будет минимум собственного опыта – хотелось бы рассмотреть существующие международные стандарты в области управления знаниями.
Начнем, наверное, с самого популярного бренда в сфере стандартизации – ИСО .
Представьте себе, что существует целый отдельный стандарт, посвященный системам управления знаниями (ISO 30401:2018).
Но сегодня я бы не стал на этом останавливаться.
Прежде чем понять, «как» должна выглядеть и работать система управления знаниями, нужно согласиться с тем, что она в принципе нужна.
Возьмем, к примеру ИСО 9001:2015 (Системы менеджмента качества).
Как следует из названия, это стандарт, посвященный системам менеджмента качества.
Чтобы пройти сертификацию по этому стандарту, организация должна обеспечить прозрачность и бесперебойность своих бизнес-процессов, продуктов и/или услуг.
Другими словами, сертификат означает, что в вашей компании все работает четко и слаженно, вы понимаете, какие риски несет текущая организация процессов, умеете контролировать эти риски и стремитесь их минимизировать.
При чем здесь управление знаниями? Вот с чем это связано:
Так, стандарт ИСО в области менеджмента качества гласит, что для обеспечения качества своей деятельности предприятие должно заниматься управлением знаниями.7.1.6 Организационные знания
Организация должна определить знания, необходимые для управления ее процессами и достижения соответствия продукции и услуг.Знания необходимо поддерживать и делать доступными в необходимом объеме.
При рассмотрении меняющихся потребностей и тенденций организация должна учитывать имеющиеся у нее знания и определять, как получить или предоставить доступ к дополнительным знаниям и обновить их.
ПРИМЕЧАНИЕ 1. Организационные знания – это знания, специфичные для организации; в основном основаны на опыте.
Знания – это информация, которая используется и обменивается для достижения целей организации.
ПРИМЕЧАНИЕ 2. База знаний организации может быть: а) внутренние источники (например, интеллектуальная собственность; знания, полученные на основе опыта; уроки, извлеченные из неудачных или успешных проектов; сбор и обмен недокументированными знаниями и опытом; результаты улучшений процессов, продуктов и услуг); б) внешние источники (например, стандарты, научные круги, конференции, знания, полученные от клиентов и внешних поставщиков).
И ниже, во вложениях: Требования к организационным знаниям были введены для: а) защита организации от потери знаний, например, из-за:
б) поощрение организации к приобретению знаний, например, посредством:
- Текучесть кадров;
- невозможность получения и обмена информацией;
- обучение в процессе работы;
- наставничество;
- бенчмаркинг.
Правильно, альтернативы нет - "должен" .
В противном случае нонконформизм, и до свидания.
Уже один этот факт, кажется, намекает на то, что это не необязательный аспект в организации, как часто трактуется управление знаниями в ИТ, а обязательный компонент бизнес-процессов.
Более того, стандарт описывает, какие риски призвано устранить управление знаниями.
На самом деле они вполне очевидны.
Давайте представим.
нет, не так - вспомните, пожалуйста, ситуацию из вашей карьеры, когда вам очень нужна была какая-то информация для работы, а ее единственный носитель находился в тот момент в отпуске/командировке, вообще уходил из компании или просто болел.
.
Ты помнишь? Думаю, почти каждому из нас приходилось с этим сталкиваться.
Что вы чувствовали в тот момент? Если через какое-то время руководство отдела расследует срыв сроков проекта, оно, конечно, найдет виноватых и на этом успокоится.
Но лично для вас в тот момент, когда вам понадобились знания, понимание того, что «виноват РМ, который поехал на Бали и не оставил никаких инструкций на случай вопросов».
Конечно, он виноват. Но это не поможет решить вашу проблему.
Если знания документированы в системе, доступной людям, которым они могут понадобиться, то описанная «курортная» история становится практически невозможной.
Таким образом обеспечивается непрерывность бизнес-процессов, а значит, отпуска, выезды сотрудников и пресловутый автобусный фактор не представляют угрозы для предприятия – качество продукта/услуги останется на привычном уровне.
Если в компании есть площадка для обмена и хранения информации и опыта, а также сформирована культура (привычка) использования этой платформы, то сотрудникам не придется ждать ответа коллеги несколько дней (или даже искать несколько дней).
для этого коллеги) и отложите выполнение своих задач.
Почему я говорю о привычке? Потому что недостаточно создать базу знаний, чтобы люди начали ею пользоваться.
Мы все привыкли искать ответы на свои вопросы в Google, а интранет чаще всего ассоциируется у нас с заявками на отпуск и досками объявлений.
У нас нет привычки «искать информацию о Agile-фреймворках» (например) в интранете.
Поэтому, даже если у нас будет крутейшая база знаний за одну секунду, никто не начнет ею пользоваться в следующую секунду (а то и в следующем месяце) — нет привычки.
Изменение привычек – это болезненно и отнимает много времени.
Не все к этому готовы.
Особенно, если они «работали одинаково» 15 лет. Но без этого инициатива компании в области знаний потерпит неудачу.
Вот почему эксперты УЗ неразрывно связывают управление знаниями с управлением изменениями.
Также стоит обратить внимание на то, что «При рассмотрении меняющихся потребностей и тенденций организация должна учитывать имеющиеся у нее знания…», т.е.
развивать культуру обращения к предыдущему опыту при принятии решений в меняющемся мире.
И еще раз обратите внимание "должен" .
Кстати, этот небольшой параграф стандарта многое говорит об опыте.
Обычно, когда речь идет об управлении знаниями, стереотипы начинают предполагать картину базы знаний с сотнями документов, размещенных в виде файлов (регламентов, требований).
Но ISO говорит об опыте.
Знания, полученные из прошлого опыта компании и каждого ее сотрудника, – это то, что позволяет избежать риска повторения ошибок, сразу принимать более выгодные решения и даже создавать новый продукт. В наиболее зрелых компаниях в сфере управления знаниями (в том числе и российских, кстати) управление знаниями рассматривается как средство увеличения капитализации компании, создания новых продуктов, разработки новых идей и оптимизации процессов.
Это не база знаний, это механизм инноваций.
Помогает нам понять это более подробно Руководство PMBOK от PMI .
ПМБОК представляет собой справочник по совокупности знаний по управлению проектами, справочник по проектному управлению.
В шестом издании (2016 г.
) этого руководства появился раздел, посвященный управлению интеграцией проектов, который, в свою очередь, включает подраздел, посвященный управлению знаниями проекта.
Данный параграф создан «на основе комментариев пользователей руководства», т.е.
стал продуктом опыта использования предыдущих версий руководства в реальных условиях.
А реальность требовала управления знаниями! Основной вывод новинки — «Реестр извлеченных уроков» (в описанном выше стандарте ISO он, кстати, тоже упоминается).
При этом, по мнению руководства, составление этого реестра должно осуществляться на протяжении всей реализации проекта, а не по его завершению, когда придет время анализа результата.
На мой взгляд, это очень похоже на ретроспективы в agile, но об этом я напишу отдельный пост. Дословный текст в PMBOK звучит так:
Управление знаниями проекта — это процесс использования существующих знаний и создания новых знаний для достижения целей проекта и содействия обучению в организации.Я не буду копировать сюда весь большой раздел руководства.Область знаний управления интеграцией проектов требует интеграции результатов, полученных из всех других областей знаний.
Новые тенденции в интеграционных процессах включают, помимо прочего: … • Управление знаниями проекта Все более мобильный и меняющийся характер рабочей силы также требует более строгого процесса определения знаний на протяжении всего жизненного цикла проекта и их передачи целевым аудиториям, чтобы знания не были потеряны.
*** Ключевые преимущества этого процесса заключаются в том, что ранее приобретенные знания организации используются для получения или улучшения результатов проекта, а знания, полученные в результате текущего проекта, остаются доступными для поддержки операций организации и будущих проектов или их этапов.
Этот процесс продолжается на протяжении всего проекта.
Вы можете ознакомиться с ним и сделать соответствующие выводы.
Приведенных выше цитат, на мой взгляд, вполне достаточно.
Мне кажется, наличие такой детализации в задаче ПМ по управлению проектными знаниями уже говорит о важности этого аспекта при работе над проектами.
Кстати, часто слышу тезис: «Кому нужны наши знания в других ведомствахЭ» Я имею в виду, кому нужны эти уроки? На самом деле часто можно увидеть, что единица рассматривает себя как «единицу в вакууме».
Вот мы со своей библиотекой, а есть остальная компания, и знания о нашей библиотеке ей ни к чему.
Про библиотеку - возможно.
А как насчет сопутствующих процессов? Тривиальный пример: во время работы над проектом было взаимодействие с подрядчиком.
Например, с дизайнером.
Подрядчик оказался так себе, сорвал сроки и отказался выполнить работу без дополнительной оплаты.
РМ записал в журнал учета извлеченных уроков, что работать с этим ненадежным подрядчиком не стоило.
При этом где-то в маркетинге тоже искали дизайнера и наткнулись на того же подрядчика.
И на данный момент есть два варианта: а) если в компании устоявшаяся культура повторного использования опыта, коллега из маркетолога посмотрит в реестре извлеченных уроков, не обращался ли кто-нибудь уже к этому подрядчику, увидит негативный отзыв от нашего ПМ и не будет тратить время и деньги, общаясь с этим ненадежным подрядчиком.
б) если в компании нет такой культуры, маркетолог обратится к тому же ненадежному подрядчику, потеряет деньги, время компании и может сорвать, например, важную и срочную рекламную кампанию.
Какой вариант кажется более удачным? И заметьте, что полезна была не информация о разрабатываемом продукте, а о процессах, сопровождающих разработку.
И оно оказалось полезным не другому РМ, а сотруднику совсем другого направления.
Отсюда вывод: разработку нельзя рассматривать отдельно от продаж, техподдержку от бизнес-аналитики, а ИТ от административного управления.
У каждого в компании есть опыт работы, который будет полезен кому-то еще в компании.
И это не обязательно будут представители смежных сфер.
Однако техническая сторона проекта также может оказаться полезной.
Попробуйте провести аудит проектов в вашей компании за последние несколько лет. Вы будете удивлены, сколько велосипедов было изобретено для решения подобных задач.
Почему? Потому что не налажены процессы обмена знаниями.
Итак, управление знаниями, согласно руководству PMI, является одной из задач PM. Как мы видим, две известные организации, проводящие платную сертификацию по своим стандартам, включают управление знаниями в свои списки обязательных инструментов для контроля качества и проектной работы.
Почему менеджеры ИТ-компаний до сих пор считают, что управление знаниями — это документация? Почему кулер и курилка остаются центрами обмена знаниями? Все дело в понимании и привычках.
Я надеюсь, что ИТ-менеджеры постепенно будут все больше осознавать сферу управления знаниями, а устная традиция перестанет служить инструментом сохранения знаний в компании.
Изучите свои стандарты работы – в них много интересного! Теги: #Управление проектами #Образовательный процесс в ИТ #стандарты ИТ #управление знаниями #обмен знаниями #управление знаниями #стандарты #управление проектами #обмен опытом #PM #iso #PMI #pmbok #обмен знаниями #обмен знаниями #обмен опытом
-
Обзор Инструмента Rss
19 Oct, 24 -
Винительный Дизайн
19 Oct, 24 -
Что Такое Унифицированные Коммуникации
19 Oct, 24