Управління знаннями

Управління знаннями — це практика фіксувати те, що знає компанія, зберігати це там, де люди справді можуть знайти потрібне, і стежити, щоб інформація лишалася правдивою. Сюди входять політики, описи процесів, інструкції, рішення та їхні причини і той неформальний досвід, який зазвичай живе в головах трьох-чотирьох людей.

Перевірка проста: коли людина звільняється, іде у відпустку або переходить в іншу команду, скільки з її знань лишається придатним для решти? Якщо відповідь — те, що вона встигла написати в чаті, управління знаннями в компанії немає, є лише везіння.

Явні та неявні знання

Два типи знань поводяться зовсім по-різному, і саме через плутанину між ними більшість ініціатив зупиняється.

• Явні знання вже записані або їх легко записати: політики, шаблони, інструкції, довідник співробітника, документація до систем. Тут завдання переважно про зберігання і про те, щоб знайти потрібне за кілька секунд.
• Неявні знання — це судження, напрацьоване досвідом: який клієнт спокійно сприйме затримку, чому правило взагалі з'явилося, що тихо ламається, якщо змінити одне налаштування. Вони погано лягають у документи і передаються через менторство, job shadowing та спільну роботу пліч-о-пліч.

Компанії зазвичай вкладаються в перше і ігнорують друге, а потім виявляють розрив того тижня, коли сильний спеціаліст подає заяву.

Що зберігає база знань компанії

• Матеріали для старту: те, що новачок читає під час пребордингу та в процесі онбордингу, включно з інструментами, доступами і тим, до кого з яким питанням іти.
• HR-політики, до яких повертаються, а не читають один раз: правила відпусток, політика відвідуваності, витрати, бенефіти, політика щодо відсутностей.
• Інструкції до процесів: як подають і погоджують заявки, як працюють HR-воркфлоу, що відбувається під час офбордингу.
• Шаблони і довідкові документи — тут управління знаннями перетинається з кадровим документообігом.
• Продуктові, клієнтські та галузеві знання, які ведуть самі команди.
• Ухвалені рішення: що вирішили, коли і чому, щоб та сама дискусія не відкривалася щокварталу.

Власник статті вирішує все

У кожної статті має бути конкретний власник і дата перегляду. Сторінка без власника за рік стане неправдивою і тихо навчить людей не довіряти вже всій базі. HR веде свій розділ, кожна команда — свій, а внутрішня комунікація доносить зміни, щоб оновлена політика дійшла до людей, а не лежала на сторінці, куди ніхто не повертається.

З чого почати без піврічного проєкту

1. Два тижні записуйте питання, на які HR і тімліди відповідають повторно. Цей список і є першим змістом бази, відсортованим за реальним попитом.
2. Опишіть десять найчастіших відповідей короткими статтями. Одне питання — одна стаття, відповідь у перших двох реченнях.
3. Домовтеся про одне місце зберігання. Дві паралельні локації дають дві версії правди і руйнують довіру швидше, ніж повна відсутність бази.
4. Призначте власників і дати перегляду до публікації, а не після.
5. На повторні питання давайте посилання на статтю замість нової відповіді, а якщо питання виникло через незрозумілий текст — правте статтю.
6. Неявні знання закривайте окремо: спільна робота, записані розбори, свідоме зворотне менторство в обидві сторони.

Як зрозуміти, що це працює

Кількість статей не доводить нічого. Корисні сигнали: яка частка повторних питань тепер закривається посиланням, як швидко новачки виходять на повну продуктивність, який відсоток статей переглядали за останні дванадцять місяців і чи аналіз потреб у навчанні далі показує прогалини, які могла б закрити документація. База, де половину сторінок не чіпали два роки, — це не актив, а ризик із пошуковим рядком.

Управління знаннями в PeopleForce

База знань у Desk будується з категорій і статей, які пишуться в блоковому редакторі: заголовки, списки, таблиці, зображення, відео, вкладені файли, виноски та блоки коду. Кожна стаття проходить стани чернетки, редагування і публікації, зберігає історію версій із можливістю відкотитися і шукається по всій базі. Доступ задається правилами аудиторії: за замовчуванням стаття видима всім, або звужується до відділу, локації чи іншого атрибута, а правила категорії успадковуються статтями всередині неї. Окремі права розділяють тих, хто читає, тих, хто редагує, і тих, хто керує всією базою.

Поруч Core HR зберігає документи і дані співробітників, на які посилаються статті, чеклісти онбордингу ведуть новачка до потрібних статей із першого дня, а звернення в Desk показують, які саме питання повторюються — це найчесніший беклог, який може мати база знань.