Техника 5.2: Атрибуты статьи KCS

Атрибуты статьи состоят из трех полей метаданных: статус статьи, аудитория статьи (ранее известная как видимость статьи) и источник возникновения. Статус статьи говорит нам об уровне уверенности в ее структуре и содержании. Аудитория статьи добавляет дополнительный уровень контроля, который позволяет создавать бизнес-правила, разрешающие различный доступ разным аудиториям. Источник — это еще один уровень сегментации базирующийся на том создана ли статья на базе коллективного опыта (большинство статей по методологии KCS), или же это статья описывающая некие политики компании и/или созданная на их базе.

Статус статьи

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

• WIP (Work in Progress) - черновик
• Draft - законченная, но непроверенная статья
• Validated (Approved) - проверенная статья
• Archived - архивный

WORK IN PROGRESS (WIP) — черновик статьи, в которую копируются симптомы - то как описал проблему клиент, некоторая информация об окружении (ОС, версия продукта и т.д.) , но который еще не содержит решения.

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

WIP статьи являются временными. Как правило, они должны стать либо законченными/непроверенными, либо проверенными, либо их следует удалить. Если проблема так и не будет решена, а заявка закрыта по инициативе клиента, сотрудник поддержки должен решить, было ли в статье зафиксировано что-либо ценное. Если заявка уже не обрабатывается и в статье нет ничего ценного, то ее следует удалить.

WIP помогает сотрудникам управлять незавершенной работой.

DRAFT (Not Validated) — статья завершена в том смысле, что в ней есть решение, но мы либо до конца не уверены в нем или структуре и содержании из-за отсутствия обратной связи. Например, статья может быть создана Кандидатом KCS, который еще не обладает достаточными навыками для проверки статьи.

Этот статус дает нам возможность зафиксировать опыт решения проблемы не тратя время на анализ того, подойдет ли тот же самый опыт для разрешения аналогичных проблем будущем. Люди часто не решаются записывать весь свой опыт в виде статей в базу знаний, если они не уверены в в своем решении на 100% . Статус DRAFT / ""Не проверено"" позволяет указать: «Вот что я сделал в этой ситуации, но мне не удалось проверить решение или ответ».

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

Кандидаты KCS (люди, изучающие практики KCS) могут создавать и изменять только непроверенные статьи, которые затем проверяются более опытными сотрудниками.

VALIDATED — статья считается полной, проверенной и пригодной для использования внешней аудиторией. Проверка достигается за счет применения решения у разных клиентов либо на базе собственного опыта. Это могут сделать сотрудники с ролями KCS Contributor, KCS Publisher и KCS Expert (KDE).

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

Поля статуса, аудитории и источника хранятся как часть метаданных статьи KCS. По мере того, как статья развивается, используется, проверяется и улучшается, эти поля могут обновляться.

Статья может переходить из качества «Не проверено» в «Проверено» несколько раз в течение своего жизненного цикла. Процесс будет варьироваться в зависимости от:

• Зрелости KCS в организации

• Использовании статьи

• Роли сотрудника, создающего статью

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

Примеры перехода статусов

WIP

• WIP создается в момент времени, когда выполняется первый поиск по проблеме, если таковая не найдена.

• WIP переходит в DRAFT, если:

• Статья завершена, но создана Кандидатом KCS .
• Статья завершена, создана Участником (Contributor) или Издателем (Publisher) KCS, но нет уверенности в работоспособности решения.
• WIP становится Validated, если:
• Над статьей работает сотрудники с ролями Участник (Contributor) KCS или Издатель (Publisher) KCS. Они уверены, что статья решила заявленную проблему и соответствует стандарту качества.
• Важно отметить, что статьи WIP должны существовать только во время работы над проблемой и пока связанный с ней тикет еще открыт. Когда инцидент закрыт, в статью должно быть добавлено решение (которое вы отправили клиенту в тикете) и перемещена в категорию Draft - «Не проверено» или Validated - «Проверено» в зависимости от уровня сотрудника и уверенности в предоставленном решении. Если проблема не решена, а инцидент закрыт, как правило, WIP следует удалить или перевести в архив. Исключением, которое следует учитывать при работе с нерешенными вопросами и статьями WIP, является ситуация, когда в WIP содержится ценная повторно используемая информация. Например, это может произойти, если в статье был описан процесс диагностики.

Draft (Not Validated) и Validated (Не проверено и Проверено)

• Непроверенная становится проверенной, если статья обрабатывается/повторно используется сотрудниками с ролями Участник KCS, Издатель KCS или Тренер; у них есть уверенность и подтверждение клиента, что предоставленное решение помогло; статья соответствует стандарту содержания.

Archived (В архиве)

• Любая статья может быть заархивирована с целью исключения ее из поисковой выдачи

• Заархивированная статья может быть восстановлена, если того потребует ситуация

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

Единственными исключениями из этого правила являются ситуации, когда Эксперты в предметной области анализируют паттерны, тренды. поисковые запросы и т.д., и создают или публикуют статьи на их базе.

Аудитория статьи: кто что увидит

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

Или, по мере развития статьи, аудитория может расширяться. Например:

• ВНУТРЕННЯЯ — статью смогут увидеть только сотрудники поддержки.
• ДОСТУПНАЯ ВНУТРИ ОРГАНИЗАЦИИ — группа, связанная с определенным доменом продукта, темой, должностной обязанностью, отделом и т. д.
• ДОСТУПНАЯ ПАРТНЕРАМ - Кто-то, кто не является сотрудником, но действует как доверенное лицо организации.
• ДОСТУПНАЯ КЛИЕНТАМ — клиенты или пользователи наших продуктов или услуг. Доступ к этим статьям обычно предоставляется через веб-портал самообслуживания для зарегистрированных пользователей.
• ДОСТУПНАЯ ВСЕМ - Статья в открытом доступе. Распространенной практикой является оптимизация и индексация этой статьи для общедоступного поискового устройства, такого как Google.

Публикация статей дла конкретной аудитории производится в зависимости от реального использования:

• В начале внедрения KCS (Этапы 2 и 3) проверенные статьи публикуются на основе их повторного использования. Спрос привлекает наше внимание к тем статьям, которые имеют ценность, и поэтому должны быть видны внешним пользователям (партнерам и клиентам). Этот процесс публикации должен быть использован на временной основе , и на финальном этапе внедрения (Этап 4) ее заменяет модель публикации «точно в срок». К сожалению, организации часто застревают на этапе «публикация только после внутреннего повторного использования» и в результате не развиваются дальше. Пока мы учимся использовать KCS, запрос или повторное использование — это разумный способ узнать, что следует публиковать. Однако, чтобы полностью воспользоваться плодами KCS, мы должны стремиться к быстрой публикации получаемых знаний. .
• В зрелой среде KCS (Этап 4) мы используем цель 90/0: мы должны как можно быстрее делиться большей частью того, что мы знаем. 90 % статей в базе знаний должны быть опубликованы на момент закрытия тикета. Это повышает эффективность портала самообслуживания.

На Этапе 4 внедрения KCS у нас должно быть много сотрудников с ролью Издатель (Publisher) KCS, и мы должны принимать решения о публикации статьи на стадии их создания. На этапе 4 большинство созданных статей будут сразу находиться в состоянии Validated/Проверено, а для аудитории задано значение "Доступная Всем".

Издатель (Publisher) KCS может сразу же изменять проверенную статью. Остальные же, если если видят, что статья не соответствует стандарту контента KCS или иным образом требует доработки, исправления, обновления или улучшения, должны пометить статью и перевести ее в статус Not Validated/Draft. Некоторые инструменты Управления Знаниями позволяют тем, кто не является Издателем KCS, редактировать неопубликованную версию статьи, в то время как текущая опубликованная версия остается нетронутой. Такой подход так же возможен и даже более удобен, поскольку экономит время издателя, которому нужно только утвердить изменения. Как правило, статьи, которые были опубликованы и доступны в Интернете, не должны удаляться , если они были помечены для доработки. Хотя, если сотрудник видит, что статья представляет риск для клиентов, то он должен как можно быстрее уведомить издателя или своего руководителя.

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

Чтобы управлять аудиторией статей их статусами, мы рекомендуем создать Матрицу состояния статей и ролей, которые имеют на них права (показан пример)

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

Еще раз: Процесс публикации на основе повторного использования должен быть временным. На финальном этапе внедрения (Этап 4) ее заменяет модель публикации «точно в срок».

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

Источник статьи

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

Атрибут источника, используемый в сочетании с ролями KCS, позволяет нам управлять статьями и их состоянием в соответствии с требованиями соответствия.

Мы предлагаем два атрибута источника:

• На основе опыта

• На основе соответствия

Атрибут источника "на основе опыта" представляет собой атрибут по умолчанию для всех статей создаваемых по методологии KCS.

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

Стагнация KCS

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

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

Ценность статьи KCS в зависимости от времени

"Дорога ложка к обеду"

KCS предполагает, что содержимое базы знаний отличается и должно управляться иначе, чем другие типы информации, такие как документация или официальные руководства. Знания динамичны, и их необходимо создавать, управлять и поддерживать в актуальном состоянии. По нашему опыту ценность нового знания в организациях поддержки начинает уменьшаться через 30 дней после первого обнаружения проблемы. К сожалению, многим организациям, которые не используют KCS, требуется только 60-90 дней и более для документирования и публикации новых статей. По сути они упускают окно возможностей и КПД их работы в этом случае крайне низкий.