Привет. Меня зовут Виталий Чесноков, я вырос от фронтендера до генерального директора компании QSOFT. Я постоянно искал и продолжаю искать новые способы, чтобы компания работала эффективнее.
Здесь я не буду рассказывать про управление бюджетом, качеством, бизнес-процессы и т.д. Расскажу про управление знаниями. Это менее очевидная методика, которая пока мало применяется в России.
Два слова о том, что такое управление знаниями
Управление знаниями иначе называют Knowledge Management. Иногда сокращают до KM.
Формальное определение есть в ГОСТ Р ИСО 30401-2020. Но оно описано слишком абстрактно, поэтому объясню на примерах, чтобы было проще.
В банках, нефтегазовой отрасли, атомной энергетике выстроена система управления знаниями, потому что там высока цена ошибки. А вот в остальных сферах бизнеса это редкая история.
Управление знаниями, по сути, процесс управления всей корпоративной информацией: от узкопрофессиональной до чисто организационной. Например, где заказать бумагу для принтера, какие проекты мы делали, какие технологические решения самые успешные, техническое задание на проекты разработки и т.д. Эта информация и есть знания.
Знания компании можно разделить на два типа: явные и неявные.
Явные отражены в проектной документации, технических заданиях, планах, переписках с клиентами и других документах. Их легко фиксировать.
Неявные знания — это информация о том, как организация функционирует: описание бизнес-процессов, неформальная иерархия, дресс-код, корпоративная культура, опыт сотрудников, успешные и провальные кейсы.
Неявные знания на примере управления ожиданиями заказчика. Допустим, у себя в голове заказчик уже нарисовал идеальный дизайн будущего сайта, но не говорит какой. Менеджер-новичок не знает, что эти ожидания вообще надо выявлять. Менеджер среднего уровня уже понимает, как узнать у клиента, что он хочет, может импровизировать с каждым новым заказчиком, выявлять эти идеальные образы и говорить «нет». Очень опытный менеджер не только может все это делать, но и может четко объяснить даже новичку, как выявлять эти ожидания и работать с ними.
В следующих статьях я подробно расскажу, какие знания нужно фиксировать, поделюсь реальным опытом внедрения разных практик в управлении знаниями. Но перед этим, нужно рассказать, с чего все началось.
Верните мне мой 2009: как мы начинали фиксировать знания на корпоративном портале
Оглядываясь назад, я понимаю, что первые попытки фиксировать и делиться неявными знаниями начались у нас в 2009 с корпоративных блогов.
Тогда мы просто создали блоги на корпоративном портале. Ситуация в компании на тот момент была такой: за первые 4 года работы выросла команда, но не был налажен обмен знаниями между людьми. Два разработчика на разных проектах решали одну и ту же задачу и по сути изобретали велосипед. Поэтому мы решили фиксировать эти знания в блогах. Получился такой локальный ЖЖ и Хабр, не по уровню, но по атмосфере.
В блогах разработчики писали инструкции и описывали свои типичные рабочие задачи, делись неформальными лайфхаками и комментировали друг друга. Не было модерации и цензуры, писать можно было обо всем.
Были и неформальные приколы, которые даже сейчас весело пересматривать.
У менеджеров были немного другие инициативы. На базе блогов они делали три классные штуки: обзоры книг, реалити-шоу проекта, и обучающие курсы для онбординга.
Про реалити-шоу. К нам обратился издательский центр, чтобы мы сделали для них интернет-магазин с сервисом онлайн-читалки. И в блогах мы описывали в реальном времени, как идет работа над проектом от лица всех его ключевых сотрудников. Нужно было описывать все максимально подробно, чтобы на примере этого проекта выяснить, что у нас в процессах работает хорошо, а что не очень.
На базе блогов у нас были обучающие курсы, разбитые по грейдам. Для нескольких из них записывал обучающие видео один из основателей QSOFT
А руководство описывало бизнес-процессы. Это помогало проще доносить до подчиненных свои мысли и меньше потом переделывать работу. Это было особенно важно для аккаунт-менеджеров, потому что клиент может уйти, и ошибки обходились дорого.
Сама идея фиксировать неявные знания руководства и сотрудников и открыто делиться ими была прогрессивной. Из этих неявных знаний спустя 10 лет выросла Академия QSOFT и наша собственная платформа развития знаний сотрудников.
Не думаю, что сейчас кто-то активно ведет блоги на корпоративном портале, потому что сам функционал устарел морально. Сейчас появились более удобные платформы для управления знаниями, которые отл��чаются от блогов, как новенький IPhone от кнопочного Siemens.
Но сами идеи для форматов обмена знаниями можно внедрять до сих пор: реалити-шоу из проекта, собственные курсы для сотрудников, неформальные лайфхаки и приколы.
Из этого управленческого эксперимента я бы выделил несколько инсайтов.
Положительные стороны:
неявные знания, которых нет и не будет в формальных документах, лучше фиксировать в блогах, чем вообще не хранить;
коллеги дают обратную связь в комментариях. Это помогает расти профессионально;
связь с интранетом. Отсюда конфиденциальность, сохранение экспертизы: в статьях уже описано, как работает тот или иной компонент, поэтому если человек решит уволиться, то статья в БЗ лучше, чем ничего;
можно войти в историю: уйдешь из компании, а новички будут читать твои статьи.
Отрицательные стороны:
блог нерегулярно ведется. Все-таки это почти благотворительность, а системное управление знаниями не построишь на полностью добровольных началах;
неструктурированность информации: чтобы найти нужную статью, приходилось пролистывать все блоги на портале;
отвлекаешься на шутки и личные записи. Пока смеялся, забыл про тикеты, которые надо сделать :)
Позже на основе опыта с блогами мы начали осознанно выстраивать управление знаниями у себя. Как это происходило, расскажу в следующих статьях.
