Учить, лечить, мочить: три этапа по внедрению базы знаний от стартапа до корпорации

К руководителю очереди на согласование, три раза переделываем одно и то же, а об онбординге и говорить нечего? Или наоборот – каждый клик мышкой только по инструкции? Определите, какого цвета ваша компания и какие способы управления информацией сработают у вас лучше всего. Разобраться нам поможет эксперт, который внедрял базу знаний в S7 Airlines.

Привет! Это команда TEAMLY. Делаем инновационную базу знаний, где можно не просто хранить информацию, а ещё работать над проектами и обучать сотрудников.

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

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

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

❓ Зачем тут управление знаниями

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

👉 Что подойдет для хранения: банальный флипчарт, Гугл или Яндекс. Диск. Все, что не требует расходов времени и денег.

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

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

Мы сами проходили этот этап, когда только начинали делать TEAMLY.
Продукт был ещё в разработке, в команде было 5 человек. Все сидели в одном кабинете, поэтому поделиться информацией было легко. Если чего-то не знаешь, можно было спросить напрямую даже собственника. Потом сильно выросли продукт, команда, объём знаний, и мы перестроили процессы.

❓ Зачем тут управление знаниями

На перспективу: накопить опыт и вырасти.

Когда мы немного подросли, нам пришлось онбордить новых ребят.
И мы судорожно пытались вспомнить: где там ссылка на этот документ? А это мы не описали, опять полчаса рассказывать одно и то же.
Ну и классическая проблема: вообще некогда заниматься новичком, свои задачи горят. Если бы мы сразу вели базу знаний, этого кошмара не было бы. Вторая проблема — это потеря опыта. Когда человек увольняется, его знания уходят за ним. Когда не нужно выстраивать все заново с каждым новым сотрудником, освобождается много времени на развитие. Как это сделать? Расскажет наш эксперт.

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

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

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

👉 Что подойдет для хранения знаний: здесь чаще договариваются в чатах и на планерках. Для рабочих задач подойдет Гугл или Яндекс. Диск. Но уже тут нужно между собой договориться о правилах хранения и обновления информации — потом восстанавливать это все будет сложно.

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

❓ Зачем тут управление знаниями

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

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

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

👉 Что подойдет для хранения знаний: В TEAMLY вы можете отправлять документы на согласование руководителю уже в базе знаний. Там автоматически сохраняются все комментарии и истории версий. К ним можно в любой момент вернуться. А ещё тот, кому отправили документ, получит уведомление в личный кабинет. Это очень удобно, не надо лишний раз пинговать итак занятого руководителя.

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

❓ Зачем тут управление знаниями

Хранить правила и инструкции, описывать бизнес-процессы.

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

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

Здесь опять же первичен сам бизнес-процесс хранения. ПО — это уже вторично. Проблема возникает, когда такая компания приходит за системой как за таблеткой: вот сейчас мы её установим, и она решит все наши проблемы. А этого не происходит. Всё равно на этом уровне нужно самим назначать ответственных и устанавливать правила работы с системой.

👉 Что подойдет для хранения знаний: здесь важна база знаний с четкой структурой и мощным поиском. В Тимли вы сможете создать удобную систему хранения для ваших инструкций благодаря структурированному дереву статей и отдельным рабочим пространствам для каждого отдела.

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

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

❓ Зачем тут управление знаниями

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

👉 Что подойдет для хранения знаний: для того, чтобы выиграть в конкурентной борьбе крупные компании создают целые системы управления знаниями. Туда входят корпоративный портал, база знаний, деловая соцсеть, система управления идеями, цифровой двойник сотрудника и система медиааналитики. Об истории создания такой системы мы уже рассказали в статье про “Домодедово”. На этом уровне внедрение любого ПО не будет проблемой. Даже если прямо сейчас процесс работы с ПО не устоялся, обязательно найдется человек, который об этом позаботится.

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

Алгоритм очень простой: учить, лечить, мочить.
Шаг 1. Учить
Здесь надо убедиться, что мы не требуем высшей математики от первоклашек. Мы сначала проводим демонстрацию, рассказываем, что и как в этой базе знаний устроено. А затем проверяем: а у людей получается?

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

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

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

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

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

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

Шаг 3. Мочить

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

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

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