Какие бизнес-проблемы можно решить менеджментом знаний

Поговорим о менеджменте знаний.

Когда я впервые столкнулся с этим термином, я как порядочный ИТ-шник полез в Google, чтобы посмотреть, что же там есть такого полезного для меня как для топ-менеджера, для руководителя разработки.

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

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

И есть даже люди, которые предоставляют какие-то услуги на аутсорсе, закрывающие те или иные проблемы.

Важный дисклеймер – то, о чём я буду сегодня говорить, и те вещи, которые я выясняю, мы публикуем на сайте https://pragmatic-km.guide/. Там находится наш прагматик-гайд, вики, где мы внятным человеческим языком стараемся описать, что такое менеджмент знаний.

Ключевой вопрос, который меня волновал – зачем нужен менеджмент знаний с точки зрения бизнеса, с точки зрения топ-менеджмента?

6 «зачем»

У меня получилось сформулировать 6 кейсов-примеров, которые помогут и вам что-то понять для себя.

• Первая история – про то, как вырастить экспертизу. Бывает, что сотрудники решают задачи, но какой-то экспертности и глубокого понимания того, чем они занимаются, им не хватает. Срываются сроки, страдает качество – это приводит к плохим результатам.

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

• Третья история – про то, как быстро вводить людей в курс дела. Компания растет, мы нанимаем новых сотрудников, и они очень долго въезжают в предметную область.

• Четвертая история – про то, как улучшить работу поддержки пользователей. У нас есть техподдержка, но она работает не очень хорошо, долго, иногда с ошибками. А нам хочется, чтобы сотрудники техподдержки лучше понимали, что нужно пользователям, и более оперативно обрабатывали запросы.

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

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

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

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

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

Пусть их компания называется Pied Piper, и пусть они занимаются тем, что разрабатывают искусственный интеллект, который заменит всех админов, будет строить инфраструктуру автоматизировано, и, главное, безошибочно – в соответствии с лозунгом AI for infrastructure.

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

Первая история – про то, как вырастить экспертизу

Для стартапа в области AI for infrastructure (на момент написания этого доклада и, согласно легенде — на момент создания Pied Piper) есть два важных момента:

В мире существует не так много зрелой экспертизы, что по теме построения современной инфраструктуры, что по теме искуственного интеллекта (под которым, конечно, мы понимаем Machine Learning).

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

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

Обещания оказались сорваны, а клиенты, естественно, не довольны.

Что делаем? Нанимаем еще одного человека, чтобы он разгрузил остальных, и стало лучше.

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

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

И сложные амбициозные задачи, которые бы хотелось давать и которые бы хотелось решать, им давать тоже немного страшно.

Все это – симптомы одной истории, их можно описать фразой: экспертиза не зрелая.

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

Чтобы что-то поменять, нам надо бы сначала измерить критичность незрелости нашей экспертизы.

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

• Количество экспертов – в принципе при этой проблеме можно на глаз примерно определить – человек эксперт или нет.

• Уровень офигевания сотрудников – тоже примерно понятен по глазам.

• Время онбординга – тоже достаточно легко измерить.

Какие практики и инструменты предлагает менеджмент знаний для наращивания экспертизы? Разберемся с каждым из них в отдельности.

Первый подход, который помогает наращивать экспертизу – это совместная работа. Сюда относится

• Парное программирование – не буду на нем останавливаться, вы про него наверняка слышали.

• Dogfooding – используйте сами тот продукт, который вы создаете. Это очень здорово раскрывает глаза на реальность.

• Shadowing – термин из лингвистики. Тоже можно погуглить и найти для себя что-то интересное.

Второй подход – это картирование знаний. Этот термин из менеджмента знаний, существует в разных формах.

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

• Тех. радар – сейчас подробнее расскажу.

• Локатор экспертов – по каким вопросам по какой предметной области к кому можно пойти с этим компонентом, кто лучше всего разбирается с этим модулем.

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

Следующий подход – выученные уроки (Lessons learned), обязательная история для вызревания экспертизы. Этот подход существует в разных форматах, которые перечислены на слайде. В каждом формате есть какие-то свои нюансы, которые можно погуглить, почитать. Суть примерно одна и та же: что-то произошло, мы это пережили, выдохнули и потом делаем выводы – как нам сделать, чтобы в следующий раз все было лучше.

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

Причем формат, который мы выбираем для сессии обмена знаниями, очень важен. От формата зависит то, о чем мы просим людей говорить, то, на что мы просим людей обращать внимание. Просто так собраться и обменяться знаниями – не работает. Согласно исследованиям, если мы правильно выберем формат, сессия обмена знаниями будет эффективнее на 30-40%. Форматов много. Даже вариантов мозговых штурмов много.

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

• Spotify продвинул в ИТ-сообществе термин «гильдии».

• В Community of practice (коммьюнити практиков) мы собираем всех фронтэндеров крупных корпораций, чтобы они взаимоопылялись, и, возможно, с некоторой вероятностью либо родили какие-то инновации, либо родили какие-то стандарты, либо среди них вырос какой-то лидер, который поможет всей компании. Это немного инвестиционная история.

• В Community of interest мы собираем людей, заинтересованных во внедрении какого-нибудь фреймворка – они необязательно практики.

И последний подход – обмен знаниями как бизнес-процесс.

Обмен знаниями можно рассматривать как воронку бизнес-процесса, на каждой стадии кто-то или что-то отваливается. Если причины для отвала убрать, то обмен знаниями будет идти бодрее и веселее. На эту тему я делал доклад на конференции DevOpsConf – можете посмотреть его видео.

Здесь на слайде собраны все основные приемы обмена знаниями – что выбирать, надо смотреть по вашей ситуации. Я уверен, что вы сможете это сделать, если у вас есть проблема с незрелой экспертизой.

В компании Pied Piper смогли правильно пройти этот этап, их экспертиза созрела, они смогли вырасти.

Вторая история – нужно больше экспертов

У нас есть эксперт Дима, на нем постоянно висит куча задач.

• Беклог задач эксперта расписан на полгода, в начало этого бэклога можно попасть только с помощью каких-то адских административных мер. Чаще всего, вы просто туда не попадете.

• Когда Дима идет в отпуск – работа в компании встает.

• А когда мы приходим к нему и просим, чтобы он объяснил, как это делать, Дима отнекивается: «Мне проще сделать это самому, чем объяснять. Зачем мне тратить на обучение час, если я могу сам сделать за 5 минут?».

• И когда общаешься с Димой, создается впечатление, что у него в голове море тайного знания – мы даже не знаем, о чем он знает.

В ИТ для этого случая есть термин – бас-фактор, от слова «автобус», сколько человек должен сбить автобус, чтобы деятельность компании остановилась. Здесь происходит именно такая же история.

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

Все очень просто.

• Мы берем у эксперта интервью по какой-то теме.

• Потом обмозговываем, структурируем, упаковываем в какой-то внятный формат (схема, текст и т.д.) все, что он сказал.

• И распространяем по компании.

Хорошая новость – есть люди, которые с этим регулярно работают. Сюда относятся технические писатели и специалисты по составлению электронных курсов. Их хлеб – проходить эту схему.

Есть нюанс – они не могут корректно распространить эту информацию по компании, потому что у них не хватает административного ресурса и понимания того, как компания функционирует.

И еще есть нюанс – им нужно четко ставить задачу, о чем строить контент. Всю остальную рутину они очень классно берут на себя.

Еще один подход – это научить экспертов делиться.

Чаще всего бывает так, что ваш эксперт совсем не против делиться, но он просто тупо этого не умеет. И ему нужно помочь научиться это делать.

• Первый прием – это наставничество. Оно же коучинг, оно же менторинг. Для этой цели есть очень классная школа наставников Яндекса, где учат людей становиться наставниками и делиться своими знаниями.

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

• И, конечно же, эксперт скажет вам огромное спасибо, если вы дадите ему кого-то в помощь, кто будет за него оформлять и структурировать мысли, потому что самостоятельно ему это делать очень тяжело, он эксперт в другой предметной области, не в оформлении, не в упаковке

Еще один прием, который очень классно помогает в этой ситуации – вовлечение команды в обмен знаниями.

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

Культура обмена знаниями. Есть какие-то вещи, которые люди должны начать делать на ежедневной основе.

• Например, зачастую в компании просто нет понимания того, как и куда задавать вопросы, когда они у тебя появляются. Я столкнулся с какой-то проблемой в модуле, кого мне спрашивать?

• Аналогичная проблема – что мне делать, если я хочу поделиться с кем-то знаниями.

• И то же самое – как провести сессию обмена знаниями.

В Pied Piper выбрали какие-то подходящие инструменты, внедрили их и смогли увеличить количество экспертов.

Третья история – о том, как быстро вводить людей в курс дела

По мере того, как компания Pied Piper стала расти, она начала нанимать новичков, и новички начали несколько недоумевать.

Причем начали недоумевать не только новички, но и «старички»:

• Отсутствие базовых знаний у новеньких вызвало у существующих сотрудников раздражение: «Зачем вообще наняли людей, которые не знают «базовые вещи»? Нужно нанимать хороших людей!»

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

• Им зачастую даже не понятно, в чем заключаются эти «базовые вещи».

Для быстрого введения людей в курс дела есть слово, которое вы наверняка знаете – онбординг сотрудников. Под этим словом подразумеваются:

• Организационные вопросы – где пишем задачи, что делаем с этими задачами, как написать заявление на отпуск, где кафе и т.д.

• Технический онбординг – все, что касается проектов, где какой код, где какие код-стайлы, какие архитектурные решения, как, почему принимаются.

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

• Культурные моменты. Одни компании жестко иерархичные, и что сказал начальник – то мы берем и делаем без вопросов. Другие компании более демократичные. Опять-таки, это – пропасть, через которую неплохо было бы «прокинуть» мостик.

Это – по содержанию.

Теперь – о том, какими бывают приемы онбординга:

• Самый распространенный случай – лекция от руководителя. 30-40 минут руководитель рассказывает своему подчиненному, куда он попал, а дальше решаем по ситуации.

• Более продвинутый – пишем приветственное письмо, например, email, в котором мы все эти вещи описываем, и сотрудник уже с этими материалами начинает как-то жить. В более продвинутых случаях это прямо книга, самая известная – GitLab Handbook, которая находится в интернете на сайте GitLab, Walford Handbook, Tesla Anti-Handbook. В случае Walford Handbook это прямо физическая книга с хорошей красивой полиграфией, которую вручают каждому новичку

• Кто-то не пишет контент в виде ответов на вопросы, а пишет вопросы в виде чек-листа – что человек должен узнать и сделать в первый месяц, в первые два месяца, неделю, чтобы успешно адаптироваться. И дальше человек уже сам крутится, как хочет.

• Кто-то вместо того, чтобы делать это в виде чек-листа, оформляет задачу в трекер и требует прогнать ее по статусам, отчитаться о выполнении.

• Кто-то внедряет наставничество.

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

Есть очень много софта, который помогает при онбординге. Все эти программы можно нагуглить по ключевым словам «Onboarding software for HR».

Но есть один важный нюанс.

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

Соответственно, онбординг – это не только первый день и не только рассказы о том, в какую классную компанию вы попали, это все те подробности, с которыми человек сталкивается первые 3-4 месяца.

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

Компания Pied Piper что-то из этого применила, правильно адаптировала и смогла вырасти без адской боли.

Четвертая история – как улучшить работу техподдержки пользователей

Жалобы на техподдержку – понятная проблема.

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

Хорошая новость – вы, возможно, видели диаграмму, изображенную на слайде. Для организации работы техподдержки есть фреймворк KCS (Knowledge Centered Service) – у него уже шестая редакция. Это уже очень зрелое решение.

У KCS есть очень классные гайды – читаешь и наслаждаешься.

• Adoption Guide – как применять фреймворк KCS в компании;

• Practices Guide – какие есть практики;

• Reference Guide – какие есть понятия, что они значат;

• Measurement Matters – какие есть измерения, на что они влияют.

Прочитайте обязательно – очень классно, испытаете эстетическое удовольствие.

Кроме инструкций, для работы под KCS есть специальный софт, есть сертификация для тренеров.

В компании Pied Piper фреймворк KCS применили, и стало хорошо.

Пятая история – убрать противоречия в инструкциях

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

Как нам понять, есть ли у нас проблема хаоса в документации? Есть два прикольных показателя.

• Почему-то люди, которые пишут документацию и инструкции, считают, что они пишут нетленки. Так же, как разработчики зачастую хотят писать нетленный код. А на самом деле, частота обновлений – очень важный показатель для документации. Потому что все меняется, и документы тоже должны обновляться.

• А еще – может быть, вы когда-нибудь гуглили какие-нибудь проблемы про Google Spreadsheet’s или Google Docs, и там на страничке есть кнопка «Была ли вам эта статья полезна?» Эта штука очень здорово помогает измерять процент ошибок и устареваний.

Какие подходы предлагает для решения проблемы хаоса в документации менеджмент знаний?

• Первое – это картирование

• Второе – это каталогизация. Иногда в компании тупо нет даже списка всех используемых информационных систем, а такие списки очень полезно составить.

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

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

• Целый класс решений под названием корпоративный поиск (Enterprise Search). Такие решения бывают реализованы как SaaS или Standalone-сервисы, они бывают платные или OpenSource – все, что угодно под любые размеры компании.

• Если у вас проблема с хаосом в документах, то, скорее всего, проблема с пользователями и пониманием ролей этих пользователей. Системы единого входа (Single Sign On) типа OKTA очень здорово помогают навести порядок. В любом случае, вам нужно с этим разбираться.

• Вечный холивар – нам делать интеграции существующих систем или единую платформу Sharepoint или Битрикс24. Война бесконечная, не знаю, кто прав. Я – за интеграции.

• И, конечно, если есть проблема хаоса с документами, по-любому придется работать с контентом, вычитывать его, структурировать и исправлять.

• И с людьми тоже придется работать – валидировать, договариваться. Хорошая новость – люди, которые себя позиционируют как менеджеры знаний, в том числе этим занимаются, умеют и любят это все делать.

Pied Piper прошел эту стадию и стал жить дальше.

Шестая история – как избавиться от зависимости от тайных знаний

Теперь – самая интересная тема. Люди иногда увольняются

• Во-первых, потому что они просто иногда так делают.

• Во-вторых, потому что они выходят на пенсию – такое иногда бывает.

• Иногда конфликты неизбежно приводят к увольнениям.

• Люди уходят в декрет.

• И бывают более печальные ситуации – не будем о них.

Как нам измерить критичность проблемы зависимости от тайных знаний?

• Первый показатель, по которому можно измерить эту проблему – это наличие карты знаний в физическом виде или хотя бы у кого-то в голове. Актуальность этой карты знаний и то, насколько она соответствует реальности.

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

Какие инструменты предлагает менеджмент знаний для решения проблемы зависимости от тайных знаний?

• Картирование.

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

• Конечно, очень здорово помогает практика непрерывного документирования, парное программирование и наставничество

Заключение

Итак, мне нужно было ответить на вопрос – зачем менеджмент знаний?

Мы разобрали шесть прикладных кейсов, которые показывают симптомы проблем и инструменты для их решения с помощью менеджмента знаний

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

*************

Данная статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2021 Post-Apocalypse.