Эта статья  — мое осмысление западного опыта и теории в сфере Knowledge Management. В своей прошлой статье я уже затронул тему явных и неявных знаний, и обещал раскрыть эту тему подробнее. Недавно нашел зарубежную статью о том, какие знания в бизнесе стоит фиксировать. Здесь процитирую отрывки из неё и добавлю примеры из собственной практики. 

Теория

В рамках бизнеса обычно различают два типа знаний: явные и неявные. Некоторые исследователи отдельно выделяют ещё и встроенные знания.

Явным знаниям свойственны организованность и упорядоченность. Такие знания фиксируют в документах.

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

Встроенные знания — это знания, воплощенные в корпоративной культуре, процессах, рутинах. 

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

Мой комментарий:

Не всегда можно абсолютно четко разграничить явные и неявные знания. Например, перед тем, как сотруднику техподдержки закрыть задачу, сначала нужно все протестировать и описать для коллег. И мы создали шаблон-алгоритм для этой задачи в блоге. Этот алгоритм не был “тайным знанием”. Просто его никто не задумывался фиксировать, поэтому кто-то делал правильно, а кто-то нет. Так неявное знание превратилось в явное.

Алгоритм сдачи задач для техподдержки
Алгоритм сдачи задач для техподдержки

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

Взаимодействие этих типов знаний лежит в основе управления знаниями и теории организационного обучения. 

Теперь остановимся подробнее на каждом из этих видов. А также рассмотрим, как с ними работать с помощью системы управления знаниями.

Явные знания

Явные знания еще называют «know-what» («знаю, что»). Они содержатся в проектной документации, технических заданиях, планах, переписках с клиентами и тикетах таск-трекеров. 

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

Мой комментарий: 

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

Все названия артефактов кликабельны и ведут на страничку с объяснением: как работать с этим артефактом. Для каждого артефакта мы делаем чек-лист готовности и видеобзор, где проговариваем подводные камни или контекст.
Все названия артефактов кликабельны и ведут на страничку с объяснением: как работать с этим артефактом. Для каждого артефакта мы делаем чек-лист готовности и видеобзор, где проговариваем подводные камни или контекст.

Это хороший пример сочетания явного и неявного знания. Те смыслы, которые зафиксированы в документации — это явные знания, которые легко систематизировать и хранить. А бизнес-процессы, частью которых является документ, мы проговариваем в формате видео. 

Главные задачи в управлении явными знаниями: обеспечение доступа к необходимым знаниям, а также их хранение, анализ, правка, обновление или сброс.

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

Неявные знания

Такие знания интуитивны, трудноопределимы, во многом основаны на опыте. Они часто зависят от контекста и носят личный характер. Их трудно передать — они глубоко укоренены в деятельности и внутренних процессах компании.

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

Неявные знания сложно (порой даже невозможно) кодифицировать. Это как попытаться написать статью о нашем восприятии человеческой мимики. Мы понимаем ее интуитивно, полагаясь на личный опыт — такое знание практически невозможно грамотно сформулировать и передать в виде текста.

Мой комментарий:

Когда мы только начинали фиксировать неявные знания, мы сделали запись видеолекций одного из основателей QSOFT. Он делился своим опытом и неявными знаниями, которые не нагуглишь. Несмотря на то, что они записывались 10 лет назад, эти инсайты до сих пор применимы на практике в работе. 

Очень живая тема до сих пор: “Как управлять рисками на проекте”. Объясню на абстрактном примере. Ну, например, у вас в квартире может протечь труба. А может и не протечь. Ты не можешь заменить трубу, но можешь снизить вероятность наихудшего сценария: например, проверять периодически, не капает ли, и где находится вентиль, который перекрывает воду. 

Точно так же и в работе с рисками. Половина успеха: грамотно определить потенциальные риски, чтобы с ними было можно работать. Например, надо получить готовые API со стороны внутренней команды. Можно просто сидеть и ждать. Но наиболее вероятно, что сроки будут сорваны или вы получите не то, что надо. А можно договариваться, описывать спецификацию, и регулярно встречаться для синхронизации сроков.

Кажется, что это какая-то абстракция, и зачем вообще её фиксировать. Но в реальной работе менеджер настолько завален текучкой, что о таких вопросах он не успевает думать. Хотя это вещи фундаментально более важные.

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

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

Мой комментарий:

Я думаю, с помощью ИТ-решений можно фиксировать и обмениваться в том числе и неявными знаниями. Есть готовые комплексные платформы для управления знаниями, где сотрудники просто выполняют рабочие задачи прямо в ней, а результаты автоматически сохраняются в базе знаний. Например, пишете и обсуждаете сценарий презентации, а потом он сохраняется в базе знаний, а не в разрозненных гугл-доках. Туда же можно записать и комментарии и вопросы клиента после неё. А потом, когда надо будет делать следующую презентацию, просто идешь на платформу и смотришь готовое решение. Ещё на таких платформах можно формировать сообщества экспертов внутри компании. Там эксперты обсуждают какую-то проблему или решение — и это помогает фиксировать неявные знания наполовину автоматически. 

Встроенные знания

Некоторые исследователи выделяют дополнительный тип — встроенные знания. 

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

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

Мой комментарий:

Например, в небольшом отеле работники привыкли записывать все на бумагу и вести таблички в Excel. Но клиентов стало больше, и понадобилась CRM-система. После того, как её внедрили, и все привыкли ей пользоваться, знание о том, как в ней работать становится рутиной и превращается во встроенное знание. Как правило, такие инициативы всегда идут “сверху”. 

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

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

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

Эффективное управление встроенными знаниями — задача крайне сложная. Поэтому компании, преуспевшие в этом деле, могут получить значительное конкурентное преимущество.

Резюме: 

Мысль поделить знания, на явные, неявные и встроенные действительно интересная. Думаю, чтобы компания росла, нужно не только систематизировать явные знания. Важно фиксировать и передавать и неявные знания тоже. Причем знания и джуна, и сеньора одинаково важны. И чем лучше налажен процесс обмена знаниями, тем больше развивается экспертиза сотрудников. Но, выстроить процессы так, чтобы люди хотели делиться своими знаниями — это нетривиальная задача. В следующих статьях я поделюсь, какие методы мы пробовали, чтобы выстроить эти процессы у себя в компании.

Комментарии (1)


  1. itGuevara
    15.12.2022 22:54

    Метазнания = знания о знаниях.

    Знания об одном и том же «ручном» процессе:

    - в регламенте;

    - в голове у исполнителя процесса (при этом он, зная, как нужно сделать, делает иначе).

    Знания об одном и том же «автоматическом» процессе:

    - код (возможно даже с комментариями), понятный только машине;

    - рабочая документация на программу (она может не синхронизироваться с кодом, т.е. может не совпадать).

    Еще есть знания о том же процессе, но со «стороны» - это как окружение полагает, как работает процесс.

    Полагаю, что для «ручных» процессов «Явные знания» могут быть в трех «хранилищах»:

    - знания «из мира идей»;

    - регламент по процессу;

    - «голова» исполнителя в процессе (его понимание алгоритма и бизнес-правил).

    Рассмотрим простой процесс \ алгоритм. Знания «из мира идей» - это в целом образ знаний (образ стула обычно всем понятен). Это абстракция, но она есть, хоть обычно не полная и не подробная.

    В реальном процессе образ знаний проецируется на «мир вещей»: часть знаний «упакована» в регламенте по процессу. Часть знаний этого регламента «подгружено» в «оперативно-запоминающее устройство» исполнителя – человека (память человека). Если вдруг что-то он подзабыл, то может снова почитать регламент и догрузить. Обычно текстовые регламенты – не отличаются логичностью (последовательности изложения), имеют «много букв», сложно найти что нужно и некогда читать. Есть графические регламенты, но там тоже много проблем.

    В итоге исполнитель - человек только частично владеет информацией, спроецированной из «объективной составляющей». Сотни тысяч (а может и миллионы) страниц регламентов одной крупной гос-компании, особенно из отрасли сильно «за регламентированной», например, госбанки, имеет основную цель не путеводителя по процессу для его исполнителей. Регламенты по 100-300 страниц нужны обычно для двух задач: а) найти крайнего если «что-то пошло не так» б) предъявить регулятору при проверке: при этом, такой «регламент для регулятора» содержит много фраз из документов самого регулятора, но понять, как устроен процесс – почти невозможно.

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

    Часто работает такой принцип: большой начальник говорит малому начальнику: «делай как хочешь (не важен сам процесс), но выдай хороший результат». Тут вообще знания о процессе могут замыкаться внутри подразделения малого начальника и не выходить наружу. Неявные знания могут быть вообще только в голове одного исполнителя. Большому начальнику «если что» проще на рынке взять нового малого, если предыдущий не справился.  

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

    Иное дело со знаниями в ПО. Автоматические операции в ИТ-системах подразумевают: когда человек нажал кнопку «выполнить», то происходит набор автоматических операций. Алгоритм процесса зашит в код ПО. Главное: если нет сбоев, то исполнение будет ровно как указано в коде. Правда сам пользователь обычно не знает, что же конкретно происходит по «нажатой кнопке»: эксплуатационная документация также объемна и может содержать другую логику, чем реально запрограммирована. Современный BPMN помогает, но не очень (в Low Code в реальности оказывается "много кода", и сам BPMS - ограниченного применения).   

    Фактически артефакты «из мира вещей» для ПО – это рабочая (не эксплуатационная) документация. Есть Process Mining, но он тоже пока не позволяет рядовому пользователю получить информацию: «как работает его процесс».

    С одной стороны, четкий регламент и «ни шагу сторону» - это часто хорошо:

    - в ручном процессе, исполнитель имеет четкую и подробную инструкцию;

    - в автоматическом, весь рабочий день сводится к нажатию утром «одной большой Красной кнопки «Сделать работу»;

    - в автоматизированном: жми весь день кнопку «далее».

    Человечество обязано своим существованием некоторым людям, которые не доверились четкому регламенту, а смогли «капнуть глубже» (хотя подобное промедление могло привести к «не успели с ответным ударом»): Уильям Бассетт, Станислав Петров. 

     

    Итого: исполнитель-человек, может действовать:

    А) «существуют явные знания в регламенте» - «перенос явных знаний в голову»: т.е. выполнить так «как задумано», причем объективно-формализовано задумано;  

    Б) «существуют явные знания в регламенте» - «перенос явных в голову лишь частично»: в регламенте все есть, но исполнитель выполнил их не так, при этом считая, что работал по регламенту (субъективные явные знания в голове не соответствуют объективным, т.е. формализованным);

    В) «существуют явные знания в регламенте» - «в голове совсем иное»: зная, как нужно сделать, исполнитель сделал иначе (Уильям, Станислав), «подчерпнув» знания «из мира идей»;

    Г) «не существуют / скудные явные знания в регламенте», т.е. регламент не четкий или «много букв» (иголка в стоге сена). Тут также несколько сценариев.

    Проблема, как документировать сложные процессы «ручная составляющая + автоматическая», включая что происходит «по нажатию кнопки», - сегодня большая и нерешенная проблема. Обычно даже нет оценки «качества» регламентов, один из подходов: попробуйте по «пухлому» текстовому нарисовать схему процесса, например, EPC. Часто такие текстовые регламенты – всего лишь «обязательная» макулатура и назвать их «явными знаниями» - скорее всего, - не верно. Когда-нибудь появится ПО, которое сможет по текстовому регламенту автоматом построить схему процесса и тогда загрузив в него эти тонны обязательной нормативной «макулатуры» станет понятно их реальное качество.  

    «Корень зла» тут во многом в том, что компании не
    публикуют свои процессы и не обмениваются по ним информацией.