Техника 4.2: Отметить или исправить

В культуре KCS сотрудники службы поддержки берут на себя ответственность за контент; они следуют простому правилу «отметить или исправить». Сотрудники с соответствующими правами могут устранять незначительные проблемы в моменте или добавлять дополнительную информацию,в статью. Если таких прав не имеется, или же не хватает экспертизы в данной области, то статьи должны помечаться и инициировать процесс, который привлечет внимание эксперта в предметной области. Эти модификации, основанные на реальном использовании (спросе), ведут к постоянному, непрерывному совершенствованию базы знаний.

Если мы видим что-то, что, по нашему мнению, неправильно или не имеет смысла, нам нужно предпринять одно из двух действий: отметить это или исправить. Концепция «отметить или исправить» применяется как к ошибкам в контенте, технической точности или полноте, так и к ошибкам стиля.

Исправить: если мы уверены в своей экспертизе и у нас есть прав на редактирование.
Пометить это: если мы не уверены в своей экспертизе или у нас нет прав на редактирование.

Исправить или создать новую статью?

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

Как правило, для каждого решения и причины должна быть одна статья KCS. Несколько решений для разного окружения (Операционной системы, версии продукта и т.д.) и одна и та же проблема или симптом не должны быть в одной статье. Однако это не абсолютное правило, и критерии должны разрабатываться на основе опыта с каждым конкретным продуктом. Статьи будут развиваться по мере использования, и иногда объединяться или разделяться по мере накопления дополнительного опыта. Решения должны основываться на том, что лучше или понятнее для целевой аудитории статьи: что будет иметь для них наибольший смысл.

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

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

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

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

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

Статьи, описывающие одну и ту же проблему, но для разных целевых аудиторий. Целевые аудитории могут по разному видеть симптому и уметь применять решение. Поэтому даже если "под капотом" это одна и та же проблема это могут быть две разные статьи.
Статьи, которые описывают совершенно разные проблемы и симптомы, но имеют одинаковые причину и решение. Первоначально эти статьи не будут отображаться в одном поисковом запросе. Но со временем, когда эти статьи используются и модифицируются, они начнут отображаться в одном поисковом запросе, после чего их имеет смысл объединить
Наличие двух статей с разными симптомами с одинаковым решением не обязательно означает избыточность. Причина тоже имеет значение. Можно иметь одно и то же решение для двух совершенно разных вопросов. Если причина другая, то проблемы, скорее всего, уникальны, и поэтому избыточности не существует. Когда вы найдете две статьи с разными проблемами и одинаковым решением, рекомендуется оценить статьи, чтобы увидеть, являются ли они двумя разными описаниями одной и той же проблемы. Обе могут просто иметь разные симптомы. В этом случае возникает избыточность и статья должна быть объединена. Вы также можете найти две статьи с похожими описаниями и разными решениями. Это тоже избыточность. В этом случае статьи тоже должны быть объединены.

Дублирующиеся статьи

Дублирование статей неизбежно если организация действительно практикует KCS. В какой-то степени дубликаты статей являются необходимым компонентом успешной практики управления знаниями. Повторяющиеся статьи становятся проблемой, когда в поисковых запросах начинают появляться несколько статей с похожими симптомами и одинаковым решением.

Есть две причины дублирования статей.

Первая - продуктивная, естественно, рассматривается в методологии KCS. Человек, столкнувшийся с проблемой, может описать ее совершенно иначе или в другом окружении, чем то, как документирована уже существующая статья в базе знаний (статья А). Сотрудник вряд ли найдет существующую статью и создаст новую, отражающую опыт, описанный клиентом (статья B). Если клиенты часто сталкиваются с проблемой, то сотрудники будут выполнять поиск с различными симптомами и могут найти статью А. Они должны обновить симптомы, чтобы включить новый клиентский опыт, если он еще не указан в статье. Другие сотрудники, занимающиеся этой проблемой, могут найти статью B и должны так же обновить описание проблемы. Если эти статьи используются часто, со временем они обе появятся в поиске. Сотрудник, который первым увидит их обе, должен объединить статьи A и B. Если мы будем следовать методике «Повторное использование — это проверка» и постоянно обновлять статьи на основе опыта клиентов, дубликаты со временем будут одновременно появляться в поисковых запросах. Это точка, в которой мы должны объединить их.

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

Сотрудникам ставится цель по созданию определенного количества статей. Это определяет поведение создания, а не повторного использования.
Сотрудники не следуют подходу «искать раньше, искать чаще» и/или «искать, прежде чем сохранять», и в результате они создают статьи о проблемах, которые уже были решены и зафиксированы в базе знаний.
Корпоративная культура не поощряет редактирование статей, которые, как считается, «принадлежат» другим, поэтому сотрудники вместо этого создают дубликаты статей (индивидуальное владение статьями — смерть для успешных практик управления знаниями).

В любом случае нам нужен способ борьбы с повторяющимися статьями.

Работа с дубликатами: объединение

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

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