01.11.2021 | Автор: OleshkoV | 206 просмотров
Разработка и поддержание таксономической структуры

Эта статья подготовлена по материалам Дженни Доти в блоге Enterprise Knowledge и посвящена интересной, но пока еще очень слабо освещенной у нас теме - таксономии. В ее основу легли следующие публикации:

В них автор делится своим опытом создания, внедрения и поддержания корпоративной таксономии. Сразу оговорюсь: речь не идет о таксономии единственной базы знаний, которую только планируют запускать. Речь идет о ситуации, когда в компании уже существует «зоопарк» систем, репозиториев и баз и нужно создать единую корпоративную таксономию, на которую будет опираться весь этот «зоопарк».

Создание таксономии

Первый шаг к построению таксономии – собрать весь материал, который уже существует в компании: предыдущие варианты таксономии, любые контролируемые списки контента, примеры контента, логи поисковой системы и т.п. Когда все собирается в одном месте, можно обнаружить, что в разных системах одно и то же поле (например, тип документа) может иметь разное содержание. Часто в таком случае берется за основу один из вариантов, а остальные списки игнорируются. Это неправильно: нужно постараться объединить эти списки, проработав общую структуру, чтобы не упустить ничего важного. Исключение – так называемый «золотой список», который хранится в одной системе, а другие системы на него ссылаются. Если такой есть, то его можно принимать за основу даже при наличии альтернативных вариантов. Но даже в этом случае нужно убедиться, что он соответствует следующим требованиям:

  • Точность: термины в списке четко описывают контент. Эти термины можно часто увидеть в тексте контента. Проверить точность можно, выполнив ручную проверку или с использованием инструментов семантического анализа.
  • Полнота: список полностью описывает весь контент. Проверить полноту и удобство использования разработанного списка можно на фокус-группе пользователей (попросить их заполнить метаданные для своих документов).
  • Поддержка: есть процедура курирования списка, которая обеспечивает его точность, полноту и удобство использования. Список хранится централизованно и регулярно пересматривается для внесения необходимых изменений.
  • Процесс: список используется автоматически; обеспечена его интеграция со всеми необходимыми системами. Для этого используется инструмент управления таксономией, которой поддерживает процедуры предложения и одобрения правок.
  • Управление: изменения или дополнения списка контролируются, чтобы обеспечить его качество и долговечность. Есть план управления и ответственные за отслеживание изменений сотрудники.

В случае создания новых «золотых списков» путем объединения нескольких уже существующих желательно привлекать профильных экспертов для расшифровки терминов и выработки общего согласованного глоссария.

При создании таксономии нужно постоянно держать в голове основные сценарии ее использования. Чаще всего это нахождение материала через поисковик (тут обязательно нужно учитывать синонимы разных терминов), навигация по базе (тогда таксономию придется оптимизировать для удобства навигации), управление контентом (нужно добавлять теги и поля вроде типа контента или статуса: черновик/опубликовано/отклонено). Если таксономия будет использоваться для настройки чат-ботов или поисковиков с рекомендациями контента, она будет более сложной и глубокой, чем для простой навигации пользователей базы. Необходимость добавления каждого нового поля метаданных должна быть согласована с конечной целью создания таксономии («не плодите сущности без надобности»).

Для каждого из озвученных выше сценариев могут использоваться не все поля метаданных. На рисунке ниже приведен пример таблицы метаданных, разработанной для базы знаний. В этом примере для создания меню навигации принято решение разбить контент по функциям (это удобно для пользователей). Тема документа будет использоваться как словарь синонимов при поиске и для настройки фильтров для поиска. Со словарем синонимов никаких сложностей нет, а вот с фильтрами все уже не так просто: во многих системах фильтры поиска могут отображаться только как плоские списки, а в нашем примере поле «тема» содержит три уровня иерархии. Кроме того, это поле включает 400 терминов – пользоваться ими как списком фильтра нереально. Возможно, здесь есть смысл отображать в фильтрах только верхний уровень иерархии по полю «тема», который включает 15 терминов. Но это решение желательно обсудить с потенциальными пользователями системы (провести небольшое исследование).

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

Внедрение таксономии

Важно не только разработать точную и удобную таксономию, но и правильно ее внедрить. Поскольку внедрение новой таксономии – длительный проект, есть смысл проводить его итерационно. Для этого тоже придется постоянно держать в голове основные сценарии ее использования. Если в нашем примере (на рисунке выше) бизнес-цель – улучшение результатов поиска контента, связанного с обслуживанием клиентов и формированием предложений для них, то мы можем решить сначала добавить поля «тема», «тип документа», «функция» и «месторасположение клиента», а уже на второй итерации добавить «этап проекта». Поэтапное добавление метаданных на большом объеме контента позволит раньше начать получать выгоды от использования новой таксономической структуры.

Также нужно учитывать особенности информационной системы, в которой будет разворачиваться таксономия – например, поддерживает ли она многоуровневые иерархические списки или множественные фасеты. Если перед вами стоят более сложные задачи (построение онтологии, графов знаний или применение искусственного интеллекта) или таксономия будет использоваться разными системами, стоит рассмотреть использование специальных инструментов для управления таксономией (вот здесь можно посмотреть обзор таких систем).

Трудности, с которыми приходится сталкиваться при внедрении таксономии:

  • Ограничения системы: могут быть проблемы с хранением/отображением иерархической структуры, из-за невозможности хранения синонимов терминов, из-за невозможности отображения списков со множественным выбором, трудности с индикацией нужных полей. Часто эти ограничения можно обойти (например, сделать структуру более плоской, добавить синонимы в поле для ключевых слов и т.д.), но нужно понимать, какую цену за это придется заплатить: прилагаемые усилия к настройке такой структуры, удобство использования и т.п.
  • Ограничения и обновления самой таксономии: в процессе внедрения можно столкнуться с потребностью доработки изначально выработанной таксономической структуры. Например, понадобится добавить какое-то поле метаданных, тип контента, новые синонимы для поддержки работы поисковика.
  • Заполнение полей метаданных: протегировать весь объем контента в соответствии с новой таксономией вручную может быть очень непростой задачей. Здесь могут помочь инструменты автотегирования. Для максимально точной настройки могут понадобиться оба подхода. Например, с помощью скриптов миграции могут быть заполнены те поля, которые в новой системе не отличаются от старой, инструменты текстового анализа помогут проставить тематические категории, а вручную будут заполнены новые поля метаданных.

По мере разворачивания новой таксономии нужно постоянно мониторить обратную связь от пользователей, чтобы оперативно на нее реагировать и вносить нужные изменения.

Поддержание таксономии

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

  • опять и снова – всегда держать в фокусе конечную цель;
  • понимать, какие есть ограничения и возможности и какое влияние внесенные изменения могут оказать на другие системы;
  • тщательно документировать все изменения, причины их внесения и любые особенности системы, с которыми вы столкнулись и под которые пришлось адаптироваться.

К задаче добавления новых полей метаданных нужно подходить очень аккуратно, т.к. есть существенный риск наложения разных списков, пересечения и дублирования терминов внутри одного списка и т.п. Перед тем, как добавить новую категорию, полезно задать себе несколько вопросов:

  • Мы собираемся добавить в репозиторий новую группу контента?
  • Какие есть примеры контента, которые представляют новый термин, который мы хотим добавить в таксономию?
  • Мы проверили уже существующие списки, чтобы убедиться, что новый термин не пересекается с ними?
  • Мы можем определить границы уникального контента, к которому будет применяться этот термин?

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

Дженни Доти рекомендует несколько лучших практик для организации этого процесса:

  1. Начните это делать. Соблазн идеально спланировать процесс управления со всеми ролями и ответственностями очень велик, но практика показывает, что со временем все равно придется вносить в него изменения. Поэтому лучше не затягивать, начать хоть с чего-то, а потом итерационно вносить необходимые правки. За основу можно взять любую из моделей, предложенных на схемах ниже. Предусмотрите в процессе вехи или запланируйте ретроспективы, на которых вы сможете пересмотреть процесс: что работает хорошо, а что требует доработки.
  2. Стремитесь к простоте. Держите в уме стоимость и затраты времени на внесение изменений в вашу таксономическую модель и не усложняйте процесс. Чем он длиннее и запутаннее, чем больше в нем кругов согласования изменений, тем выше вероятность того, что в какой-то момент он начнет пробуксовывать, застопорится и изменения перестанут вноситься своевременно – таксономическая структура перестанет отражать реалии бизнеса. Один из способов упрощения: разделить все изменения на два типа – минимальные и максимальные – и пустить их по разным веткам сценария принятия решения (упрощенному и полному соответственно). Например, такие изменения как добавление нового термина, синонима, атрибутов считаются минимальными, и их вносит менеджер по управлению метаданными по мере необходимости. Добавление поля метаданных, новой сущности, удаление каких-то связей будут считаться более серьезными изменениями, и для их внесения уже потребуется решение управляющего комитета или рабочей группы, которая собирается на регулярной основе.
  3. Распределите зоны ответственности и организуйте регулярную коммуникацию. За внесение изменений в метаданные должны отвечать конкретные люди. На эту роль не обязательно брать человека на полную ставку – вполне возможно, что она будет отнимать всего несколько часов в месяц. Есть успешные примеры, когда эту роль делают ротационной: один человек выполняет ее в течение года, а затем его сменяет другой эксперт. Тогда эта ответственность не воспринимается как тяжелая дополнительная нагрузка. Роли и ответственность удобно расписать по матрице RACI. Например, за добавление нового поля метаданных вроде «тип контента» может нести ответственность менеджер по таксономии (R), проконтролировать должен лидер этого направления (A), проконсультироваться нужно с профильными экспертами (C), а уведомить об изменениях придется всех пользователей (I).
  4. Все, что можно, автоматизируйте. Использование технологий для поддержки управления метаданными может сильно упростить вам жизнь, особенно когда масштабы работы увеличатся. Они позволяют вам централизованно вносить изменения во все системы, с которыми связана таксономия, минимизируя ручной труд; обеспечивают контроль доступа и стандартизацию процесса внесения изменений в метаданные; стандартизируют использование метаданных разными информационными системами, обеспечивая контроль качества по всей организации. Успешные примеры автоматизированных процессов: пометка на архивацию/удаление контента или метаданных, которые не используются регулярно; автокатегоризация контента и автозаполнение части метаданных на основе анализа текста; автоматизация подачи предложений по доработке метаданных пользователями прямо из системы, в которой они работают. Конечная цель автоматизации – снизить нагрузку ручной рутинной работы на команду управления метаданными.


Рис. 1. Иерархическая модель управления таксономией



Рис. 2. Плоская модель управления таксономией

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

  • согласованность: все элементы таксономии распределены по контенту в точном соответствии с его содержанием;
  • удобство использования: структура и язык таксономии интуитивно понятны конечным пользователям;
  • полнота: элементы таксономии применимы ко всем единицам контента в системе;
  • готовность: таксономия встроена во все предусмотренные сценарии потенциального использования и/или может быть улучшена для обеспечения поддержки расчета более сложных метрик.

Следующее направление для оценки результатов проекта – привязка к бизнес-цели. В нашем примере в начале статьи целью разработки таксономии было улучшение результатов поиска, поэтому к нему можно применить такие метрики: время, затрачиваемое на поиск информации, и сокращение числа случаев неуспешного поиска. Также можно анализировать поисковые запросы пользователей (термины, которые они используют).

Любые метрики, которые вы решили примерить в своем проекте, желательно измерить и зафиксировать до старта проекта, чтобы позже иметь базу для сравнения, поскольку отслеживание динамики здесь интереснее, чем абсолютные значения показателей.


P.S. Если тема баз знаний, таксономии, онтологии для вас актуальна, обязательно походите по блогу Enterprise Knowledge и поищите ответы на свои вопросы. Там немало интересных материалов – думаю, многие ответы для себя вы найдете.

Инструменты / 01.11.2021 | Просмотров: 206 | Добавил: OleshkoV | Всего комментариев: 0 / Теги: инструменты управления знаниями, базы знаний
ОБ АВТОРЕ
Виктория Олешко Олешко Виктория, бизнес-тренер, консультант, фасилитатор, главный редактор сайта SixSigmaOnline.ru.
Хотите узнать больше об управлении знаниями? Присоединяйтесь к группе на Facebook. Связаться с автором через Facebook или LinkedIn.

Поддержать автора на Patreon

ПОХОЖИЕ МАТЕРИАЛЫ


  Добавить комментарий
avatar
SixSigmaOnline.ru © 2009-2021            Хостинг от uWeb