Как создать базу знаний, чтобы она стала «интеллектуальным активом» компании
Создавая базу знаний, каждый преследует свои цели и решает свои проектные задачи, использует свои инструменты и программные средства. Однако для чего бы и с помощью чего бы не создавалась база знаний, она обязательно должна приносить компании максимальную пользу. Как этого добиться?
В сентябре 2020 года я выступила спикером IV-й конференции «Управление корпоративными знаниями», проходившей в рамках недели корпоративного обучения. Мой мастер-класс «Как создать корпоративную базу знаний, чтобы она стала «интеллектуальным активом» компании» заинтересовал собравшихся, и я решила сделать из материалов выступления статью. Буду рада если текст поможет вам в работе. Буду рада, если кто-то из вас захочет в комментариях обсудить этот пост.
Источник
Универсального сценария «Как создать базу знаний», который бы подходил всем и всегда, нет и быть не может. Обусловлено это как разными подходами к организации баз, так и разными IT-инструментами. А вот общие требования, своеобразный cookbook, — как раз предмет моей статьи.
Опыт большого многоуровневого проекта поддержки информационной системы позволяет выделить три основных принципа, лежащих в основе любой успешной базы знаний. Она должна быть:
- понятной;
- актуальной;
- доступной.
Написать понятно для всех
Источник
Текст статьи из базы знаний должен быть понятен всем, кто будет её читать. Притом понятен с первого прочтения, ибо скорее всего второй раз её читать просто не будут. Статья не должна быть слишком длинной или чрезмерно короткой. Материал должен быть изложен так, чтобы трактовки его содержания были однозначными, и не нужно было переводить с «бухгалтерского» или «IT-шного» на «человеческий».
Например, статья, описывающая решение типовой проблемы, написанная в стиле »… перед входом в личный кабинет очистите кэш», скорее всего вызовет вопросы, а вот если дополнить его алгоритмом очистки кэша, написанным «для вашей бабушки», то ответ будет понятен всем.
Ситуация становится острее, когда база знаний используется как FAQ для внешних пользователей, уровень подготовки которых разнится от бабушек и дедушек, которые не смогли освоить смартфон, до суперпрофессионалов этой области.
На первый взгляд, кажется, что достичь этого невозможно: если статья написана для «чайника», то погруженному в тему она будет избыточной, а если ориентироваться на профи, то «чайнику» потребуется «перевод». Как быть?
Есть много инструментов, помогающих решить проблемы. В Департаменте корпоративных систем ЛАНИТ мы используем три подхода.
1. Ревью от ведущего эксперта предметной области. Процесс направлен на повышение качества материалов базы знаний (далее БЗ). Суть в том, что эксперт проверяет корректность изложения материала, в том числе логичность и последовательность изложения.
Источник
2. Обратная связь от пользователей в виде оценки и предложений по расширению/сокращению/изменению формулировок, порядка изложения/структурирования и т. п. по результатам использования материала. Обратную связь могут оставить все заинтересованные. Предложения и пожелания прорабатываются. Технически это может быть реализовано в виде оценок ответов от пользователей, лайков, благодарностей и т. п.
3. Структурирование. Этот инструмент условно можно разделить на два типа воздействий:
- административное воздействие — регламентированный порядок изложения в едином стиле, порядок фиксации изменений, дополнений и т. п.;
- технические решения — использование макросов и надстроек, позволяющих раскрывать подробности и расшифровки только в случае, если в них есть необходимость. Это решает вопрос разного уровня подготовки читателей: для специалиста статья будет максимально коротко изложенной на языке профессиональных требований, а для новичка будет содержать расшифровки терминов и ссылки на статьи по смежным вопросам.
Например, статьи, описывающие алгоритм решения типовых проблем, у нас имеют вот такую структуру:
Всегда актуально
Однажды разместив информацию в базе знаний, нужно всегда поддерживать её в актуальном состоянии. У всех пользователей базы знаний всегда должно быть доверие к материалам, размещенным в ней.
По сути, knowledge manager должен иметь свою систему мониторинга, в которой будут свои триггеры и четко описанные алгоритмы реагирования.
Например, для базы знаний службы поддержки информационной системы триггером будет служить выход новой версии, изменение законодательства и т. п. Разработка набора триггеров и действий при их наступлении, а также определение ответственных за их выполнение — задача, решение которой обеспечивает значительную долю успеха базы знаний.
Сработавший триггер означает, что нужно оперативно скорректировать материалы. Для того, чтобы обновление не стало кошмаром, на этапе размещения материалов необходимо продумать, как оптимизировать количество статей и при необходимости автоматически отбирать нужные по заданным параметрам.
В качестве инструмента, позволяющего осуществить автоматический отбор статей, мы используем классификаторы и статусы (статусная модель с определенным алгоритмом переходов). При этом сложная задача — создание классификаторов так, чтобы их состав был достаточным, но не избыточным.
Пример статусной модели:
Как не создать информационную «мусорку» вместо базы знаний
Статьи, отвечающие на неактуальные вопросы или имеющие узко сформулированные заголовки, — путь к созданию информационной «мусорки» вместо базы знаний. Заголовок, сформулированный недостаточно широко, означает, что в нужный момент найти такую статью смогут только те, кто знает, что она есть в базе знаний. Остальные начнут решать задачу с нуля и создадут на основании этого решения статью-дубль.
Например, заголовок «Шаблоны заявлений» вполне корректен, но сформулирован узко. Искать будет легче, если добавить в него ключевые слова и написать так: «Шаблоны заявлений: отпуск, отгул, удаленная работа, увольнение, перевод».
Решить проблему помогает статистика использования материалов базы знаний. Опираясь на статистику использования, мы можем найти редко используемые и либо отправить их в архив (если материал утратил актуальность), либо расширить, обеспечив популярность в дальнейшем.
Статьи, собранные по принципу Lego из констант и переменных, снижают затраты на базу знаний
Есть правило, к которому мы пришли не сразу, но которое значительно экономит время на поддержание актуальности базы знаний. Это правило — никакого дублирования! Информация фиксируется один раз, далее используются ссылки на нее. Технически есть масса возможностей «вживлять» константы в нужные места по тексту статьи так, чтобы читатель даже не знал о том, что статья как конструктор состоит из частей.
Почему «не летит»
Даже самая актуальная база знаний, содержащая ответы на все востребованные вопросы, может «не взлететь», если найти нужную информацию сложно.
Решить проблему поиска можно структурированием и многоуровневой классификацией. Причём классификация должна быть не только на уровне разделов каталога БЗ, но и с метками по разным тематикам (например, если у нас база знаний службы поддержки пользователей, то по темам, личным кабинетам и т.д.). Каждый пользователь может отобрать перечень статей по заданным критериям, используя форму расширенного поиска.
Для того, чтобы поиск был максимально качественным для конкретного пользователя в базе знаний реализована ролевая модель доступа. Это, во-первых, решает вопрос потенциальной утечки информации: пользователю доступны только те материалы, которые подходят ему по роли в проекте или в организации в целом, а, во-вторых, сужают перечень материалов, среди которых производится поиск, повышая качество результатов.
Мобильность — наше всё
Для мобильности и в силу популярности Telegram дополнительно развиваем чат-бота.
Бот реализован в Telegram и доступен с любого устройства пользователя. Уровень доступа к информации через бот соответствует уровню доступа к сервисам компании. По запросу ответ можно получить в том числе из wiki.
Каждый ответ можно оценить. Система оценок позволяет своевременно корректировать как ответы, так и классификаторы. Вопросы, ответы на которые найдены не были, собираются отдельно и выступают идеями для развития базы знаний.
Рассмотренные принципы — не исчерпывающий список требований к базе знаний, сформулированный за четыре года активной работы над несколькими проектами, в том числе над базой знаний службы поддержки большой государственной информационной системы. Кроме того, следует отметить, что все принципы и правила работают тогда, когда в базе знаний заинтересованы все её пользователи и авторы. Главные метрики для оценки заинтересованности — количество использованных в работе материалов и количество правок от каждого автора. Мой личный список требований постоянно расширяется и в последний год появляется всё больше нюансов к требованию структурирования статей. Охотно поделюсь им в следующей статье.
