Привет! Это Виталий Чесноков, сооснователь 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 и ВкусВилл.
Поделитесь мнением в комментариях: вы верите в то, что можно убедить сотрудников, которые скрывают номера контрагентов, вести базу знаний? Почему?
