Всем привет. После KnowledgeConf 2019 прошло уже полгода, за это время я успел выступить еще на двух конференциях и провести лекции на тему управления знаниями в двух крупных ИТ-компаниях. Общаясь с коллегами, я понял, что в ИТ пока можно говорить об управлении знаниями на уровне «новичок», а точнее, просто осознать, что управление знаниями нужно любому подразделению любой компании. Сегодня будет минимум моего собственного опыта – я бы хотел рассмотреть существующие международные стандарты в области менеджмента знаний.
Начнем, наверное, с самого популярного бренда в области стандартизации – ISO. Представьте себе, существует целый отдельный стандарт, посвященный системам управления знаниями (ISO 30401:2018). Но сегодня я бы на нем останавливаться не стал. Прежде чем разбираться «как» должна выглядеть и работать система управления знаниями, нужно договориться, что она, в принципе, нужна.
Возьмем, например, 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.
PMBOK – это руководство к своду знаний по управлению проектами, настольная книга PMа. В шестом издании (2016) этого руководства появился раздел, посвященный управлению интеграцией проекта, в который, в свою очередь, включен подраздел об управлении знаниями проекта. Этот пункт был создан «на основе комментариев пользователей руководства», т.е. стал продуктом опыта по использованию предыдущих версий гайда в реальных условиях. И реальность потребовала управления знаниями!
Основным выходом нового пункта является «Реестр извлеченных уроков» (в описанном выше стандарте ISO, кстати, он тоже упоминается). Причем, согласно руководству, составление этого реестра должно производиться на всем протяжении реализации проекта, а не по его завершении, когда приходит время анализировать результат. На мой взгляд это очень перекликается с ретроспективами в agile, но об этом я напишу отдельный пост. Дословно текст в PMBOK звучит так:
Управление знаниями проекта – это процесс использования существующих знаний и создания новых знаний для достижения целей проекта и содействия обучению в организации
Область знаний «управление интеграцией проекта» требует объединения результатов, полученных во всех других областях знаний.
Развивающиеся тенденции в процессах интеграции включают в себя, среди прочего:
…
• Управление знаниями проекта
Все более мобильный и сменяемый характер рабочей силы требует и более строгого процесса определения знаний на всем протяжении жизненного цикла проекта и их передачи целевым аудиториям так, чтобы исключить утрату знаний
***
Ключевые выгоды данного процесса состоят в том, что ранее приобретенные знания организации используются в целях получения или улучшения результатов проекта, а знания, полученные при реализации текущего проекта, остаются доступными для обеспечения операционной деятельности организации и будущих проектов или их фаз. Этот процесс осуществляется на протяжении всего проекта.
Не буду копипастить сюда весь большой раздел руководства. С ним можно ознакомиться самостоятельно и сделать соответствующие выводы. Представленных выше цитат, на мой взгляд, вполне достаточно. Мне кажется, наличие подобной детализации задачи РМа по управлению знаниями проекта уже говорит о важности этого аспекта при работе над проектами. Кстати, часто слышу тезис: «Кому нужны наши знания в других отделах?» То есть, кому нужны вот эти извлеченные уроки?
На самом деле, часто можно видеть, что подразделение рассматривает себя, как «юнит в вакууме». Вот есть мы с нашей библиотечкой, а вот есть вся остальная компания, и знания о нашей библиотечке ей никак не пригодятся. О библиотечке – возможно. А о сопутствующих процессах?
Банальный пример: в ходе работы над проектом происходило взаимодействие с подрядчиком. Например, с дизайнером. Подрядчик оказался так себе, срывал сроки, отказывался дорабатывать без дополнительной оплаты. РМ зафиксировал в реестре извлеченных уроков, что не стоит работать с этим ненадежным подрядчиком. В это же время где-нибудь в маркетинге тоже искали дизайнера и натолкнулись на того же подрядчика. И в этот момент есть два варианта:
а) если в компании хорошо налажена культура переиспользования опыта, коллега из маркетинга поищет в реестре извлеченных уроков, не связывался ли кто-то уже с этим подрядчиком, увидит негативный фидбек от нашего РМа и не потеряет времени и денег, общаясь с этим ненадежным подрядчиком.
б) если в компании нет такой культуры, маркетолог обратится к тому же ненадежному подрядчику, потеряет деньги компании, время и может сорвать важную и срочную промо кампанию, например.
Какой вариант кажется более успешным? И заметьте, полезной оказалась не информация о разрабатываемом продукте, а о сопутствующих разработке процессах. И полезной она оказалась не другому РМу, а сотруднику совершенно другого направления. Отсюда вывод: нельзя рассматривать разработку отдельно от продаж, техподдержку от бизнес-аналитики, а ИТ – от АХУ. У всех в компании есть опыт работы, который окажется полезным кому-то еще в компании. И вовсе не обязательно это будут представители смежных направлений.
Впрочем, и техническая сторона проекта может пригодиться. Попробуйте провести аудит проектов в вашей компании за последние несколько лет. Вы удивитесь, сколько велосипедов было изобретено при решении схожих задач. Почему? Потому что не налажены процессы обмена знаниями.
Итак, управление знаниями, согласно руководству PMI, это одна из задач РМа. Как видим, две известных организации, которые проводят платные сертификации по своим стандартам, включают менеджмент знаний в списки мастхэв инструментов контроля качества и работы над проектами. Почему же менеджеры в ИТ-компаниях до сих пор считают, что управление знаниями – это документирование? Почему центрами обмена знаниями остаются кулер и курилка? Все дело в понимании и привычках. Надеюсь, постепенно понимания сферы управления знаниями и у айтишных менеджеров будет становиться все больше, и устная традиция перестанет служить инструментом сохранения знаний в компании. Изучайте стандарты своей работы – в них много чего интересного!
Автор: Rodion Nagornov
