Приложение F: Часто задаваемы вопросы.

В: Я нашел две похожие статьи, какая из них правильная?

A: Сотрудники поддержки должны уметь распознавать правильный ответ, когда видят его. Они не должны предоставлять или применять статью, которую они не понимают.

В: У нас нет времени документировать все, что говорит клиент, и все, что мы делаем для решения проблемы клиента. Мы думаем, что экономия от повторного использования некоторых статей не компенсирует дополнительное время, затрачиваемое на создание этих статей. Что надо сделать?

О: Статьи можно и нужно создавать, как естественный "побочный" продукт решения клиентских заявок, не добавляя дополнительных минут к процессу решения проблемы. Чтобы добиться этого, мы должны изменить рабочий процесс и используемые инструменты таким образом, чтобы они позволяли нам быстро скопировать симптомы клиента и предоставляемое решение в черновик статьи.

В: Когда уместно создавать новую статью, а не использовать существующую?

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

В: Как заставить сотрудников поддержки записывать свои знания в базу данных?

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

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

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

В: Как мы узнаем, какие статьи должны быть опубликованы?

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

В: Мы уже занимаемся управлением знаниями! Мы публикуем наши знания в документации по продуктам и в Базе Знаний. У нас есть выделенные сотрудники - технические писатели, которые ответственны за создание и публикацию статей. Чем это отличается KCS?

О: KCS — это методология, ориентированная на сбор и структурирование знаний в рабочем процессе, а также на возможность поиска и использования этих знаний целевой аудиторией. Ключевое отличие здесь в том, что статьи, публикуемые по методологии KCS продиктованы реальным клиентским спросом, всегда актуальны и не избыточны. Выделение же отдельных сотрудников, помимо дополнительного ресурса поднимает проблему "Какой контент создавать?" и его актуальность в будущем. И если для первой десятки (или нескольких десятков) статей этот вопрос не является актуальным, то на длинной дистанции эта проблема встает в полный рост. Вот три основных проблемы при написании Базы Знаний техническими писателями:

1. Писатели оторваны от реальности. Со временем они утрачивают навыки и понимание реальных клиентских проблем.
2. "Кризис жанра" - на длинной дистанции писателям приходится придумывать темы для написания статей. Не факт , что эти статьи окажутся востребованными, и они не потратят зря свое время.
3. Находимость статей. Написание статей без контекста клиента, и без использования его "языка" снижает находимость статей клиентами в будущем.

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

A: Создание или оформление статьи другими пользователям с соответствующими привилегиями обеспечивает совместную работу и коллективное решение проблем независимо от места и времени. (Люди из разных мест и часовых поясов могут помогать друг другу решать проблемы).

В: На каком этапе решения заявки мы начинаем фиксировать информацию о проблеме в статье?

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

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

В: Зачем мне описывать проблему словами клиента, если я знаю, что то, как они описывают ее, неверно? Не загрязняет ли это базу знаний?

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