Як реалізувати базу знань 2.0 в Harmony: історія Easy Software.

Що таке База знань 2.0

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

Дізнатися більше

Як ми створили це

• Які були виклики: У Easy Software кількість внутрішніх знань для обміну стала занадто складною для попереднього рішення. Простий набір статей у категоріях вже не відповідав потребам.
• Що нам потрібно було: Ми шукали спеціалізовану програму, яка була б максимально пов'язана з Easy Redmine. Вона обов'язково повинна бути відкритим джерелом, оскільки ми підтримуємо це, а сам Easy Redmine є відкритим програмним забезпеченням.
• Яке рішення ми обрали: BlueSpice ідеально підходить за визначенням. Це відкрите рішення, спеціалізований інструмент вікі зі складною адаптабельністю та інтеграцією з Easy Redmine.

Як відбулася міграція

У нас вже були наявні дані в нашій попередній базі знань. Ми хотіли перенести багато з них до нового рішення. Дивіться, які сім кроків ми зробили:

1. Очистити дані в оригінальній базі знань – почніть до міграції. Ми рекомендуємо сортувати всі статті за датою «останнього оновлення» та починати з найстаріших.

• Ви знайдете, що багато статей зверху можна просто видалити
• Інші ви поміщаєте в певну категорію під назвою «для перегляду» - ви оновите їх пізніше
• Деякі можна оновити негайно
• Решта можуть залишатися такими, які є

Ще два поради:

• Якщо більше людей будуть переглядати статті, можна якось позначити їх або встановити користувацьке поле - наприклад, «Переглянуто».
• Також перевірте назви статей. Якщо вони містять проблемні символи, вони можуть викликати проблеми під час міграції. Ось деякі поради на mediawiki.org про назви сторінок та легальні символи назв.

Дізнатися більше

2. Встановити базу знань 2.0 – технічна доставка функції. Оскільки ми працюємо на Easy Cloud, це було зроблено майже автоматично

3. Зробити деякі тестові міграції – ми не були впевнені у результаті, тому зробили тестову міграцію

• Ми перевірили назви сторінок, форматування вмісту (заголовки, абзаци, посилання та зображення) та категорії
• Ми перевірили, скільки це займе часу (у нас було понад 900 статей для міграції)
• Ми внесли необхідні зміни в вміст оригінальної бази знань на основі наших висновків з тестової міграції
• Ми «оновили» додаток бази знань 2.0 - видалили всі дані

4. Інформація для наших користувачів

• Ми повідомили їх про дату виробничої міграції = після цього часу основним джерелом знань є база знань 2.0. Після цього часу користувачі матимуть лише доступ для читання до оригінальних статей (тільки для посилання та порівняння), як вони виглядають зараз і раніше
• Ми провели кілька раундів навчання користувачів та підвищення кваліфікації адміністраторів

5. Виробничий імпорт

• Настала день, коли ми натиснули кнопку, і міграція була запущена
• Після нашої перевірки ми знизили дозволи для всіх ролей в оригінальній базі знань - в режимі тільки для читання

Дивіться процес міграції

6. Внутрішня підтримка

• Ми призначили деяких колег та канал в Microsoft Teams, де наші користувачі могли задавати будь-які питання про функціонування бази знань 2.0
• Деякі проблеми після міграції були виявлені в виробництві. Оскільки ми все ще мали оригінальну базу знань активною, ми змогли вирішити кожну проблему відповідно

7. Вимкнути оригінальну базу знань

• Після близько 6 тижнів запитів на внутрішню підтримку зникли
• Ми вимкнули оригінальну базу знань з нашого додатку Easy Redmine
• Ми рекомендуємо зробити резервну копію перед видаленням плагіна

Як компанія прийняла зміни

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

У випадку Knowledge Base 2.0 очевидним є те, що якщо ви щось не знаєте, спробуйте спочатку знайти (лампочка в бічній панелі). Ви побачите результати не тільки у вигляді назви статті (як у вихідному Knowledge Base), але й у фактичному вмісті сторінок на перший погляд => є велика ймовірність, що ви отримаєте відповідь, не знаходячись десь ще.

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

Як пройшла реалізація

Категорії

Вони були імпортовані з вихідного Knowledge Base, що дуже добре. Але структуру (категорії та підкатегорії) технічно не можна було імпортувати. Першим, що ми зробили, було переглянути категорії, в які організовані сторінки.

Ми почали з 3 основних "вимірів" категорій:

• Аудиторія - для кого сторінка найбільш корисна - дозволяється кілька варіантів, таких як
• Продажі
• Розробка
• Маркетинг
• Всі
• Тип документу - який вид знань ділиться. Згодом кожен тип матиме свій власний шаблон, тому вони будуть виглядати стандартизовано. Найкраща практика вимагає, щоб кожна сторінка мала лише один тип документу.
• Політика
• Як зробити
• Процес
• Нотатки та записи тренінгів
• Тема - про що сторінка. Ця структура може бути більш глибокою, оскільки в компанії є багато тем. Додавання сторінки до категорії Тема є добровільним - не потрібно, якщо немає відповідної категорії.
• Продукт
• Основні функції
• Управління ресурсами
• Довідкова служба
• Agile board
• Інфраструктура
• Хмара
• Сервер
• Гібридне рішення
• Внутрішній IT
• Команди
• Outlook
• Обладнання
• Спільне обладнання
• Індивідуальне обладнання

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

Сторінки навігації

Дуже важливо, щоб користувачі добре орієнтувалися в новому додатку. Природним елементом для навігації є головне меню, яке частково можна налаштувати. Корисною додатковою опцією є домашня сторінка, яка вітає читачів, посилається на статтю про найкращі практики для Knowledge Base 2.0 та посилається на сторінки, присвячені відділам у нашій компанії.

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

Ми розглядаємо можливість використання сторінок навігації для інших критеріїв сортування (наприклад, інформація про продукт або загальні політики компанії).

[image alt="Сторі

Крок за кроком

Як тільки ви встановите свої категорії та сторінки навігації, користувачі вже зможуть працювати з ним. На початку це може здатися трохи безладним, тому ми маємо кількох призначених адміністраторів, які стежать за тим, щоб дотримуватися певного порядку.

Ми використовуємо Knowledge Base 2.0 вже кілька місяців, і ми все ще тільки починаємо. Ми розуміємо, що ми далекі від ідеального стану досконало організованої та стандартизованої вікі, яку всі користувачі (незалежно від досвіду) знають наизусть.

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

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

Висновок

Ми в Easy Software завершили процес міграції та впровадження, і тепер ваш черга. Дотримуючись цих порад та беручи натхнення, будь-яка компанія може впровад