Хабрахабр

Менеджмент знаний в международных стандартах: ISO, PMI

После KnowledgeConf 2019 прошло уже полгода, за это время я успел выступить еще на двух конференциях и провести лекции на тему управления знаниями в двух крупных ИТ-компаниях. Всем привет. Сегодня будет минимум моего собственного опыта – я бы хотел рассмотреть существующие международные стандарты в области менеджмента знаний. Общаясь с коллегами, я понял, что в ИТ пока можно говорить об управлении знаниями на уровне «новичок», а точнее, просто осознать, что управление знаниями нужно любому подразделению любой компании.

image

Представьте себе, существует целый отдельный стандарт, посвященный системам управления знаниями (ISO 30401:2018). Начнем, наверное, с самого популярного бренда в области стандартизации – ISO. Прежде чем разбираться «как» должна выглядеть и работать система управления знаниями, нужно договориться, что она, в принципе, нужна. Но сегодня я бы на нем останавливаться не стал.

Как следует из названия, это стандарт, посвященный системе менеджмента качества. Возьмем, например, ISO 9001:2015 (Quality management systems). Иными словами, сертификат означает, что в вашей компании все работает четко, слаженно, вы понимаете, какие риски несет текущая организация процессов, знаете, как контролировать эти риски, и стремитесь их минимизировать. Чтобы сертифицироваться по этому стандарту, организация должна обеспечивать прозрачность и бесперебойность рабочих процессов и производимых продуктов и/или услуг.

А вот при чем: При чем здесь управление знаниями?

7.1.6 Знания организации

Организация должна определить знания, необходимые для функционирования ее процессов и для достижения соответствия продукции и услуг.

Знания должны поддерживаться и быть доступными в необходимом объеме.

При рассмотрении изменяющихся нужд и тенденций организация должна принимать во внимание имеющиеся у нее знания и определять, каким образом получить или обеспечить доступ к дополнительным знаниям и их актуализации.

Знания организации — это знания, специфичные для организации; в основном полученные на основе опыта. ПРИМЕЧАНИЕ 1.

Знания – это информация, которая используется и которой обмениваются для достижения целей организации.

Основой знаний организации могут быть: ПРИМЕЧАНИЕ 2.

a) внутренние источники (например, интеллектуальная собственность; знания, полученные из опыта; выводы, извлеченные из неудачных или успешных проектов; сбор и обмен недокументированными знаниями и опытом; результаты улучшений процессов, продукции и услуг);

b) внешние источники (например, стандарты, научное сообщество, конференции, знания, полученные от потребителей и внешних поставщиков).

И ниже, в приложениях:

Требования, относящиеся к знаниям организации, были введены с целью:

a) защиты организации от потери знаний, например, из-за:

  • текучести кадров;
  • невозможности получения и обмена информацией;

b) стимулирования организации к приобретению знаний, например, на основе:

  • обучения на собственном опыте;
  • наставничества;
  • бенчмаркинга.

Именно так, безальтернативно – «должно». Итак, стандарт ISO в области менеджмента качества утверждает, что для обеспечения качества своей деятельности предприятие должно заниматься менеджментом знаний. Уже один этот факт как бы намекает, что это не факультативный аспект в организации, как к управлению знаниями в ИТ часто относятся, а обязательная составляющая бизнес-процессов. Иначе nonconformity, и до свидания.

На самом деле, они вполне очевидны. Более того, стандарт рассказывает, какие риски менеджмент знаний призван устранять.

Вспомнили? Давайте представим… нет не так – вспомните, пожалуйста, ситуацию из своей карьеры, когда вам очень нужна была по работе какая-то информация, а ее единственный носитель был в этот момент в отпуске/командировке, вообще уволился из компании или просто болел. Что вы в этот момент чувствовали? Я думаю, практически любому из нас приходилось с этим сталкиваться.

Но вам лично в тот момент, когда знания были нужны, никак не помогло понимание, что «виноват РМ, который уехал на Бали и не оставил никаких инструкций на случай вопросов». Если через какое-то время руководство подразделения будет разбирать срыв сроков проекта, оно, конечно же, найдет виноватого и на этом успокоится. Но вашу задачу это решить не поможет. Безусловно, он виноват.

Таким образом, обеспечивается непрерывность бизнес-процессов, а значит, отпуска, уходы сотрудников и тот самый пресловутый bus factor предприятию не страшны – качество продукта/сервиса останется на своем обычном уровне. Если же знания задокументированы в системе, доступной людям, которым они могут понадобиться, то описанная «курортная» история становится практически невозможной.

Если в компании есть площадка для обмена и хранения информации и опыта, а также сформирована культура (привычка) пользования этой площадкой, то сотрудникам не приходится ждать по несколько дней ответа от коллеги (или вообще несколько дней искать этого коллегу) и ставить из-за этого на hold свои задачи.

Потому что мало сделать базу знаний, чтобы ей начали пользоваться. Почему говорю о привычке? У нас нет привычки «поискать информацию о фреймворках Agile» (например) на интранете. Мы все привыкли искать ответы на свои вопросы в гугле, а интранет чаще всего у нас ассоциируется с заявлениями на отпуск и доской объявлений. Менять свои привычки больно и долго. Поэтому, даже если у нас в одну секунду появится крутейшая база знаний, пользоваться ей на следующую секунду (и даже на следующий месяц) никто не начнет – нет привычки. Особенно если 15 лет «и так же работали». Не все к этому готовы. Именно поэтому мастера в области УЗ неразрывно связывают управление знаниями с управлением изменениями (change management). Но без этого инициативу по работе со знаниями в компании ждет провал.

выработать культуру обращения к предыдущему опыту при принятии решений в условиях изменяющегося мира. Еще стоит обратить внимание на то, что «При рассмотрении изменяющихся нужд и тенденций организация должна принимать во внимание имеющиеся у нее знания…», т.е. И заметьте, снова «должна».

Обычно, когда речь заходит про управление знаниями, стереотипы начинают подсовывать картинку базы знаний с сотнями документов, размещенных в виде файлов (регламентов, требований). Кстати, в этом небольшом пункте стандарта очень много говорится про опыт. Знания, полученные на основе прошлого опыта компании и каждого ее сотрудника, и есть то самое, что позволяет избежать риска повторного совершения ошибок, сразу принимать более выгодные решения и даже создавать новый продукт. Но ISO говорит об опыте. Это не база знаний, это механизм для инноваций. В наиболее зрелых в сфере управления знаний компаниях (в том числе и российских, кстати), управление знаниями рассматривается как средство повышения капитализации компании, создания новых продуктов, разработки новых идей и оптимизации процессов. Разобраться в этом подробнее нам помогает Руководство PMBOK организации PMI.

В шестом издании (2016) этого руководства появился раздел, посвященный управлению интеграцией проекта, в который, в свою очередь, включен подраздел об управлении знаниями проекта. PMBOK – это руководство к своду знаний по управлению проектами, настольная книга PMа. стал продуктом опыта по использованию предыдущих версий гайда в реальных условиях. Этот пункт был создан «на основе комментариев пользователей руководства», т.е. И реальность потребовала управления знаниями!

Причем, согласно руководству, составление этого реестра должно производиться на всем протяжении реализации проекта, а не по его завершении, когда приходит время анализировать результат. Основным выходом нового пункта является «Реестр извлеченных уроков» (в описанном выше стандарте ISO, кстати, он тоже упоминается). Дословно текст в PMBOK звучит так: На мой взгляд это очень перекликается с ретроспективами в agile, но об этом я напишу отдельный пост.

Управление знаниями проекта – это процесс использования существующих знаний и создания новых знаний для достижения целей проекта и содействия обучению в организации

Область знаний «управление интеграцией проекта» требует объединения результатов, полученных во всех других областях знаний.

Развивающиеся тенденции в процессах интеграции включают в себя, среди прочего:

• Управление знаниями проекта

Все более мобильный и сменяемый характер рабочей силы требует и более строгого процесса определения знаний на всем протяжении жизненного цикла проекта и их передачи целевым аудиториям так, чтобы исключить утрату знаний

***

Этот процесс осуществляется на протяжении всего проекта. Ключевые выгоды данного процесса состоят в том, что ранее приобретенные знания организации используются в целях получения или улучшения результатов проекта, а знания, полученные при реализации текущего проекта, остаются доступными для обеспечения операционной деятельности организации и будущих проектов или их фаз.

image

С ним можно ознакомиться самостоятельно и сделать соответствующие выводы. Не буду копипастить сюда весь большой раздел руководства. Мне кажется, наличие подобной детализации задачи РМа по управлению знаниями проекта уже говорит о важности этого аспекта при работе над проектами. Представленных выше цитат, на мой взгляд, вполне достаточно. Кстати, часто слышу тезис: «Кому нужны наши знания в других отделах?» То есть, кому нужны вот эти извлеченные уроки?

Вот есть мы с нашей библиотечкой, а вот есть вся остальная компания, и знания о нашей библиотечке ей никак не пригодятся. На самом деле, часто можно видеть, что подразделение рассматривает себя, как «юнит в вакууме». А о сопутствующих процессах? О библиотечке – возможно.

Например, с дизайнером. Банальный пример: в ходе работы над проектом происходило взаимодействие с подрядчиком. РМ зафиксировал в реестре извлеченных уроков, что не стоит работать с этим ненадежным подрядчиком. Подрядчик оказался так себе, срывал сроки, отказывался дорабатывать без дополнительной оплаты. И в этот момент есть два варианта: В это же время где-нибудь в маркетинге тоже искали дизайнера и натолкнулись на того же подрядчика.

а) если в компании хорошо налажена культура переиспользования опыта, коллега из маркетинга поищет в реестре извлеченных уроков, не связывался ли кто-то уже с этим подрядчиком, увидит негативный фидбек от нашего РМа и не потеряет времени и денег, общаясь с этим ненадежным подрядчиком.

б) если в компании нет такой культуры, маркетолог обратится к тому же ненадежному подрядчику, потеряет деньги компании, время и может сорвать важную и срочную промо кампанию, например.

И заметьте, полезной оказалась не информация о разрабатываемом продукте, а о сопутствующих разработке процессах. Какой вариант кажется более успешным? Отсюда вывод: нельзя рассматривать разработку отдельно от продаж, техподдержку от бизнес-аналитики, а ИТ – от АХУ. И полезной она оказалась не другому РМу, а сотруднику совершенно другого направления. И вовсе не обязательно это будут представители смежных направлений. У всех в компании есть опыт работы, который окажется полезным кому-то еще в компании.

Попробуйте провести аудит проектов в вашей компании за последние несколько лет. Впрочем, и техническая сторона проекта может пригодиться. Почему? Вы удивитесь, сколько велосипедов было изобретено при решении схожих задач. Потому что не налажены процессы обмена знаниями.

Как видим, две известных организации, которые проводят платные сертификации по своим стандартам, включают менеджмент знаний в списки мастхэв инструментов контроля качества и работы над проектами. Итак, управление знаниями, согласно руководству PMI, это одна из задач РМа. Почему центрами обмена знаниями остаются кулер и курилка? Почему же менеджеры в ИТ-компаниях до сих пор считают, что управление знаниями – это документирование? Надеюсь, постепенно понимания сферы управления знаниями и у айтишных менеджеров будет становиться все больше, и устная традиция перестанет служить инструментом сохранения знаний в компании. Все дело в понимании и привычках. Изучайте стандарты своей работы – в них много чего интересного!

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»