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

Здесь я не буду рассказывать про управление бюджетом, качеством, бизнес-процессы и т.д. Расскажу про управление знаниями. Это менее очевидная методика, которая пока мало применяется в России. 

Два слова о том, что такое управление знаниями

Управление знаниями иначе называют Knowledge Management. Иногда сокращают до KM. 

Формальное определение есть в ГОСТ Р ИСО 30401-2020. Но оно описано слишком абстрактно, поэтому объясню на примерах, чтобы было проще. 

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

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

Знания компании можно разделить на два типа: явные и неявные. 

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

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

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

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

Верните мне мой 2009: как мы начинали фиксировать знания на корпоративном портале

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

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

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

Были и неформальные приколы, которые даже сейчас весело пересматривать. 

У менеджеров были немного другие инициативы. На базе блогов они делали три классные штуки: обзоры книг, реалити-шоу проекта, и обучающие курсы для онбординга. 

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

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

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

Сама идея фиксировать неявные знания руководства и сотрудников и открыто делиться ими была прогрессивной. Из этих неявных знаний спустя 10 лет выросла Академия QSOFT и наша собственная платформа развития знаний сотрудников. 

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

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

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

Положительные стороны:

• неявные знания, которых нет и не будет в формальных документах, лучше фиксировать в блогах, чем вообще не хранить;

• коллеги дают обратную связь в комментариях. Это помогает расти профессионально;

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

• можно войти в историю: уйдешь из компании, а новички будут читать твои статьи.

  Отрицательные стороны: 

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

• неструктурированность информации: чтобы найти нужную статью, приходилось пролистывать все блоги на портале;

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

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