В наше время базами знаний пользуются многие клиенты и компании, но далеко не все знают, что с их помощью можно решить многие внутренние проблемы. Такие как выгорание сотрудников из-за выполнения однотипной работы, избыточный штат и большие расходы на поддержку. С критериями построения эффективной базы знаний нас познакомит тимлид Анжелика Федько.
Когда мы в Plesk столкнулись с проблемами поддержки клиентов и адаптации сотрудников, то подумали, что их можно решить с помощью базы знаний. Мы разработали для себя 5 критериев, которые указывают на то, что база знаний используется не на всю катушку.
Меня зовут Анжелика Федько, я успела поработать с базой знаний с разных сторон. Например, пока была инженером технической поддержки, занималась её наполнением, созданием новых статей и актуализацией. Когда стала тимлидом, взяла на себя уже более стратегические проекты, которые нацелены не на улучшение конкретной статьи, а на базу знаний в целом. Таким образом, за 6 лет работы с базой знаний я успела рассмотреть ее с разных сторон.
Сегодня расскажу, с какими подводными камнями мы столкнулись, какие бенефиты смогли из этого извлечь, как вообще у нас проходил этот процесс и подробно разберу 5 критериев недоиспользования базы знаний.
Когда встает вопрос о систематизации знаний, первое, что приходит на ум — это создание базы знаний. Современные компании все больше времени уделяют управлению знаниями и их централизации.
Допустим, у нас есть база знаний. Мы сделали ее публичной, а значит, она доступна как нам, так и нашим клиентам. Клиенты могут быть внешние или внутренние, в зависимости от специфики компании. В нашем случае это были внешние клиенты, но это не так уж важно. Потому что спустя полгода-год обнаруживается ряд проблем, с которыми так или иначе сталкиваются все:
- Однотипные вопросы от клиентов;
- Выгорание сотрудников;
- Увеличение штата поддержки;
- Рост расходов на поддержку;
- Затянутый онбординг.
Мы поняли, что их можно решить с помощью базы знаний, но прежде чем перейти непосредственно к критериям, хочу упомянуть, что мы работаем с методологией базы знаний Knowledge-Centered Service (KCS).
Consortium for Service Innovation, которая ее разработала, подробно описала всю философию KCS в нескольких гайдах и дополнительных документах. Поэтому я не буду рассказывать теорию, а лишь поделюсь практикой из собственного опыта.
Итак, давайте разбираться с критериями.
Критерий № 1. Сотрудники прокачиваются, получают новую экспертизу, а время решения вопросов не сокращается.
В целом ситуация выглядит так. Пришла какая-то заявка, инженер ее решил. Через какое-то время приходит идентичная заявка, ее берет другой инженер и решает плюс-минус за то же самое время. И так 5-й, 20-й, 50-й раз. Но если первый инженер, который с этой проблемой столкнулся, нашел и записал решение, то почему время решения не изменилось?
Как мы выяснили, это связано с тем, что люди вместо того, чтобы написать статью в базу знаний и там задокументировать решение, все это делали в своих личных заметках. Кто-то использовал Evernote, кто-то OneNote — не принципиально. Решение напрашивалось само собой — нужно заставить всех писать в базу знаний.
Причины
И тут мы столкнулись с вопросом — почему люди этого не делают? Как выяснилось, массовых причин всего две:
- Не хочу! Чаще всего означает «Я не вижу выгоды для себя», и «Мне просто это не нравится».
- Не могу!
Давайте разбираться с каждой из этих причин.
Не хочу: не вижу выгоды для себя
В нашем случае проблема скрывалась в корпоративной культуре. Например, у нас долгое время существовал рейтинг саппорт-инженеров, то есть в течение года инженеры набирали баллы за определенные действия и KPI, и в конце года люди, которые заняли первые места, получали призы и подарки.
На тот момент я была инженером и поверьте, мне совсем не хотелось терять те преимущества в виде знаний, которые доступны только мне.
Также мы столкнулись с тем, что работа со статьями должна быть оценена, то есть включена в личный KPI сотрудника. KPI необходимо тщательно проработать. Например, нельзя ставить цели на количество созданных статей, потому что ее легко похачить, создав кучу дубликатов, которые никому не будут нужны. Гораздо эффективнее ставить цель, что каждая заявка должна заканчиваться статьей.
На самом деле наши цели менялись в зависимости от стадии развития KCS. Они подробно описаны в adoption-гайде, который предоставляет консорциум, поэтому не буду подробно на этом останавливаться.
Чтобы справиться с причиной «Не вижу выгоду для себя», у вас не должно быть конфликта между личными интересами сотрудника и тем, что вы просите. База знаний лучше всего работает в командной среде.
Не хочу: мне это не нравится
Со второй проблемой немного сложнее. Нужно разобраться, почему это не нравится человеку. Возможно, он видит какие-то причины, по которым данная система является неприемлемой.
Когда мы только внедряли KCS, выяснили, что не всем понравилось писать статьи. Были люди, которые ориентированы именно на техническую работу. Им интересно решать проблемы клиентов. Они не понимали, зачем нужно тратить время на написание какой-то статьи, если это же время можно потратить на помощь другому клиенту.
Эти сотрудники решили уволиться. Это был тот подводный камень, о котором мы не догадывались, когда начали внедрять базу знаний. В централизованном документировании очень важно, чтобы статьи писали все сотрудники. Поэтому нужно принимать риск, что некоторые люди либо сами уйдут, либо вам придется с ними попрощаться.
Не могу: не знаю как
Ещё одна глобальная причина — «Не могу». Почему-то многие менеджеры не задумываются, что люди могут не выполнять какую-то работу потому, что не знают как. Поэтому процесс документирования должен быть максимально простым и понятным.
Нам в этом помогли внутренние гайды, например, «Как создать статью». Но больше всего нам помогли шаблоны для статей. Они нужны для того, чтобы это не было сочинением на вольную тему. Чтобы человек понимал, что именно ему следует писать в статью.
Учитывая специфику нашей работы, мы выработали для себя два таких шаблона (все статьи у нас на английском языке):
- Статьи «how to» (вопрос/ответ). У них два поля: «Question» и «Answer».
- Статьи, где есть проблема: «У меня не работает». У неё три поля: «Symptoms», «Cause» и «Resolution».
Посмотрим на примеры таких статей.
Это «how to» статья на английском языке. В ней есть скриншоты и видео, которые мы всегда стараемся вставлять в статьи. Мы не используем сложные грамматические конструкции, а пишем просто директивно: «возьми это, сделай то». Так как, не все наши клиенты являются native спикерами английского языка, очень важно делать статьи максимально простыми для понимания.
Всё это позволяет максимально упростить статьи для понимания клиентами.
Следующий пример статьи-шаблона.
Здесь есть проблема. Технически такие статьи обычно сложнее, чем «how to» статьи. Но чтобы клиентам было так же просто их применить, мы расписываем их детально по шагам. Все, что остается клиенту, это команды CTRL-C и CTRL-V.
Что дает такой подход?
Когда мы заставили всех писать статьи, то увеличили скорость решения проблем на 16%.
Ещё заявки стали закрываться одним ответом на 40% чаще. Это и понятно, инженеру больше не нужно было заново придумывать решение. Он знал, что такая статья уже есть, просто брал готовое решение и отправлял клиенту.
5 критериев неэффективной базы знаний — как всё исправить Часть 2
17-18 мая на площадке из двух этажей Крокус-Экспо встретятся 2000 тимлидов и руководителей со своим опытом, инсайтами и энергией. Расписание конференции TeamLead Foundation 2022 уже готово, а купить билеты можно здесь.
Кроме того, от сервиса поиска менторов Getmentor.dev на конференции будут индивидуальные консультации с экспертами. Приглашаем вас прямо сейчас принять участие в конкурсе. Заполните форму и, возможно, именно вы выиграете 5 часов наставничества. Ментора (или менторов) вы сможете выбрать сами, сейчас в сообществе уже более 500 наставников. Больше информации — по ссылке.