Привет! Это Виталий Чесноков, сооснователь TEAMLY — платформы для совместной работы и управления знаниями. В своей практике я замечаю, что у компаний есть трудности с тем, чтобы внедрить базу знаний в рабочие процессы. В этом вопросе мне помогают разобраться эксперты.

Сегодня мне удалось пообщаться с Еленой Михайловой. Елена – бизнес-консультант, руководила проектами по разработке и внедрению базы знаний, ERP систем в S7 Airlines.

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

Как мотивировать сотрудников вести базу знаний, если они требуют вернуть гугл-доки

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

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

Шаг 1. Учить.

Сначала надо убедиться, что мы не требуем высшей математики от первоклашек. Поэтому сначала нужно всем объяснить: как и что устроено в нашей базе знаний. А лучше всего ещё и провести демонстрацию. И после этого проверить: а у людей получается?

Прежде чем перейти ко второму шагу, проверьте по чек-листу:

☑️ Мы показали демонстрацию и объяснили как это работает?
☑️ Люди пробовали пользоваться этой системой или делают вид?
☑️ У них нет технических проблем?
☑️ Владеют ли они какими-то специфическими техническими скиллами?

Шаг 2. Лечить.

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

☑️ Работа с базой знаний просто не входит в KPI сотрудника. Например, у проджект-менеджера может быть просто не записано, что за месяц он должен написать 3 статьи в базу знаний. То есть нужно просто оцифровать критерии успешности.

☑️ Если это стартап, то мотивация может быть нематериальной и держаться на авторитете руководителя. Например, если у нас будет N статей в базе знаний, мы просто вместе отпразднуем это пиццей.

☑️ Если в компании уже есть иерархия и оргструктура, то мы можем внедрять дополнительные мотивационные коэффициенты. Например, незначительные надбавки к зарплате: + 2% за выполненный KPI по базе знаний. Когда KPI не выполняется, мы просто эту надбавку не даем. Это помогает выработать привычку.

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

☑️ Может помочь просто откровенный разговор. Тут нужно объяснить прямо, но корректно. Например, мне чтобы переформатировать старую команду, приходилось объяснять: “Сейчас такая тенденция на рынке. Мы можем держаться за старую парадигму, но с ней мы не будем конкурентоспособны”.

Шаг 3. Мочить.

Если вы честно выполнили все пункты 1 и 2, но некоторые сотрудники упорно игнорируют базу знаний – пора вводить штрафы или расставаться. Поэтому компании проводят зачистки кадров: личные интересы сотрудников уже становятся несовместимы с целями компании.
Но это крайний случай. Чаще всего сотрудники скрывают от коллег телефоны контрагентов и не ведут базу знаний просто потому, что нет перед глазами примеры другой культуры и процессов. Но когда мы постепенно улучшаем то, что можно улучшить уже сейчас – мы в конечном итоге поднимаемся на уровень выше. 

ПО VS Процессы

— А можно не назначать ответственного, а просто строить процессы от ПО? Например, крупная ИТ‑компания КРОК рассказала про дорогую платформу Jive, которой пользуется даже Microsoft. И пока они ей пользовались, автоматически перенимали лучшие зарубежные практики. Кому можно повторить этот опыт?

— Зависит от уровня зрелости компании. Когда в компании выстроен синий уровень спиральной динамики* — это уровень правил, регламентов и процессов — никакое готовое ПО не будет проблемой. (Прим. подробнее про каждый уровень спиральной динамики читайте в конце статьи).

Потому что там уже выстроена система: есть прозрачные процессы работы с информацией и даже корпоративная культура. Если процесс внедрения ПО не был выстроен — в такой компании всегда найдется человек, который скажет: «Нужно что‑то менять». И сам возьмет на себя ответственность, и все выстроит.

Если мы только строим синий уровень, нам нужно сначала определиться с правилами и ответственными, прежде чем выбирать какое‑то ПО. Потому что само по себе оно не выстроит процессы вместо нас.

С чего начать вести базу знаний, если в хранилище только папки с фамилиями?

— А если у нас пока не достроен синий уровень, с чего начать формировать базу знаний?

‑Первый этап — это выработать некие правила и инструкции. Как храним, как передаем и что добавляем в базу знаний. И самое главное — кто будет отвечать за её наполнение?

— А если у нас пока не достроен синий уровень, с чего начать формировать базу знаний?

‑ Первый этап — это выработать некие правила и инструкции. Как храним, как передаем и что добавляем в базу знаний. И самое главное — кто будет отвечать за её наполнение?

Однажды я пришла в небольшую компанию и увидела, что вся информация хранится просто в виде папок с фамилиями. Например, папка “Михайлова” – и там все по Михайловой. Но вот Михайлова уволилась – и кому потом эта папка? Да никому, это же её личная папка была.

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

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

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

* Уровни развития компаний по спиральной динамике

Бежевый уровень

Уровень выживания организации. Здесь нужно хоть как-то выжить и чем-то платить зарплату. Это почти все компании, которые работают первый год, и им нужно пройти «долину смерти». Крупные компании тоже могут спуститься на этот уровень. Например, когда в 2020 закрыли границы, многие компании в сфере грузоперевозок едва не обанкротились.

Фиолетовый уровень

Многие авторы называют это «уровень племени». Мы бы назвали это «рождением стартапа». Есть небольшая команда, которая объединена не ДМС со стоматологом, а амбициями и большой идеей. Отношения в команде строятся по принципу «брат за брата».

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

Красный уровень

На этом уровне могут быть и средние, и крупные компании. Здесь авторитарный лидер. Сотрудники должны согласовывать с ним абсолютно все, вплоть до запятой. Плюсы: всегда понятно, на ком ответственность. Минусы: руководитель перегружен, из-за этого процессы тормозятся.

Синий уровень

Это уровень регламентов и правил. Здесь у компании появляется запрос на четкий регламент и бизнес-процессы. Уже внедряются системы управления бизнес-процессами: ISO 9001, BPM, CRM, ERP. Здесь есть четкое разделение ответственности, но слишком много бюрократии.

Оранжевый уровень

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

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

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

Материал подготовила команда TEAMLY. Это российский аналог Confluence
и Notion, который разработала компания QSOFT. Более 15 лет мы разрабатываем высоконагруженные системы для Enterprise-клиентов.

Если вам интересно прочитать больше материалов об управлении знаниями, загляните к нам в  Телеграм-канал.  Обсуждаем базы знаний, фреймворки по организации командной работы в ИТ и осмысляем теорию управления знаниями.  А ещё – показываем наши кейсы внедрения TEAMLY в крупных компаниях, таких как Капитал Life и ВкусВилл. 

Поделитесь мнением в комментариях: вы верите в то, что можно убедить сотрудников, которые скрывают номера контрагентов, вести базу знаний? Почему?