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

Меня зовут Анжелика Федько, я успела поработать с базой знаний с разных сторон. Например, пока была инженером технической поддержки, занималась её наполнением, созданием новых статей и актуализацией. Когда стала тимлидом, взяла на себя уже более стратегические проекты, которые нацелены не на улучшение конкретной статьи, а на базу знаний в целом. Таким образом, за 6 лет работы с базой знаний я успела рассмотреть ее с разных сторон.

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

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

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

• Однотипные вопросы от клиентов;

• Выгорание сотрудников;

• Увеличение штата поддержки;

• Рост расходов на поддержку;

• Затянутый онбординг.

Мы поняли, что их можно решить с помощью базы знаний, но прежде чем перейти непосредственно к критериям, хочу упомянуть, что мы работаем с методологией базы знаний Knowledge-Centered Service (KCS).

Consortium for Service Innovation, которая ее разработала, подробно описала всю философию KCS в нескольких гайдах и дополнительных документах. Поэтому я не буду рассказывать теорию, а лишь поделюсь практикой из собственного опыта.

Итак, давайте разбираться с критериями.

Критерий № 1. Сотрудники прокачиваются, получают новую экспертизу, а время решения вопросов не сокращается.

В целом ситуация выглядит так. Пришла какая-то заявка, инженер ее решил. Через какое-то время приходит идентичная заявка, ее берет другой инженер и решает плюс-минус за то же самое время. И так 5-й, 20-й, 50-й раз. Но если первый инженер, который с этой проблемой столкнулся, нашел и записал решение, то почему время решения не изменилось?

Как мы выяснили, это связано с тем, что люди вместо того, чтобы написать статью в базу знаний и там задокументировать решение, все это делали в своих личных заметках. Кто-то использовал Evernote, кто-то OneNote — не принципиально. Решение напрашивалось само собой — нужно заставить всех писать в базу знаний.

Причины

И тут мы столкнулись с вопросом — почему люди этого не делают? Как выяснилось, массовых причин всего две:

1. Не хочу! Чаще всего означает «Я не вижу выгоды для себя», и «Мне просто это не нравится».

2. Не могу!

Давайте разбираться с каждой из этих причин. 

Не хочу: не вижу выгоды для себя

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

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

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

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

Чтобы справиться с причиной «Не вижу выгоду для себя», у вас не должно быть конфликта между личными интересами сотрудника и тем, что вы просите. База знаний лучше всего работает в командной среде.

Не хочу: мне это не нравится

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

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

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

Не могу: не знаю как

Ещё одна глобальная причина — «Не могу». Почему-то многие менеджеры не задумываются, что люди могут не выполнять какую-то работу потому, что не знают как. Поэтому процесс документирования должен быть максимально простым и понятным.

Нам в этом помогли внутренние гайды, например, «Как создать статью». Но больше всего нам помогли шаблоны для статей. Они нужны для того, чтобы это не было сочинением на вольную тему. Чтобы человек понимал, что именно ему следует писать в статью.

Учитывая специфику нашей работы, мы выработали для себя два таких шаблона (все статьи у нас на английском языке):

1. Статьи «how to» (вопрос/ответ). У них два поля: «Question» и «Answer». 

2. Статьи, где есть проблема: «У меня не работает». У неё три поля: «Symptoms», «Cause» и «Resolution».

Посмотрим на примеры таких статей.

Это «how to» статья на английском языке. В ней есть скриншоты и видео, которые мы всегда стараемся вставлять в статьи. Мы не используем сложные грамматические конструкции, а пишем просто директивно: «возьми это, сделай то». Так как, не все наши клиенты являются native спикерами английского языка, очень важно делать статьи максимально простыми для понимания.

Всё это позволяет максимально упростить статьи для понимания клиентами.

Следующий пример статьи-шаблона.

Здесь есть проблема. Технически такие статьи обычно сложнее, чем «how to» статьи. Но чтобы клиентам было так же просто их применить, мы расписываем их детально по шагам. Все, что остается клиенту, это команды CTRL-C и CTRL-V.

Что дает такой подход?

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

Ещё заявки стали закрываться одним ответом на 40% чаще. Это и понятно, инженеру больше не нужно было заново придумывать решение. Он знал, что такая статья уже есть, просто брал готовое решение и отправлял клиенту.

Критерий №2. База знаний растет, количество клиентов увеличивается, а вопросы от них все те же.

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

Причина скрывалась в том, что мы записывали статьи языком сотрудника, а не клиента. Если взять пример статей из первого критерия: «Symptoms», «Cause» и «Resolution», то симптомы были записаны так, что их не могли найти.

Решение 

Чтобы решить эту проблему, мы начали писать языком клиента, то есть описывать все так, как это видит клиент. Например, у человека есть сайт. Он заходит на него и видит 502 ошибку — это всё, что видит клиент. Он не знает, что в одном из десятков логов на сервере есть упоминание о том, что какой-то сервис не стартует, и из-за этого не работает его сайт. Он никогда к вам с этим не придет. Он приходит именно с тем, что у него ошибка.

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

Что дает такой подход?

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

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

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

То есть, этот подход решает не только проблемы клиентов, но и проблемы сотрудников.

Критерий №3. Вы сделали крутые онбординг-тренинги, но новенькие все равно буксуют. 

Когда я слышу об этом, первое, что приходит на ум — это мы взяли не тех людей. Но мы сами провели собеседование, сами отобрали кандидатов и решили, что они подходят по каким-то критериям. Значит, проблема не в них.

Онбординг в Plesk

После того, как мы взяли человека, он на месяц попадает в отдел обучения, и тренера дают ему необходимый базис по знаниям. Только после этого он идет в команду, где ему предстоит работать. Безусловно, ему помогает тимлидер. Он приставляет к новичку опытного сотрудника из команды (коуча), который объясняет процессы, как работает база знаний, как писать статьи и прочее.

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

Когда мы об этом задумались, то решили, что нужно найти баланс между тренингами по продукту и тренингами по процессам.

Когда искать в базе знаний?

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

Пример 1

Возьмём условного инженера технической поддержки Женю. Пришла новая заявка и он начал применять все знания, которые у него есть: что-то самостоятельно делал и исследовал. Когда у него не получилось решить своими знаниями, он начал искать решение на сторонних форумах и использовать знания других инженеров, то есть спрашивал их и отвлекал. Через какое-то время идеи иссякли, и Женя решил поискать в базе знаний. Буквально с первого симптома он нашел статью, применил решение и тут же закрыл заявку.

Женя потратил много времени на изобретение колеса, несмотря на то, что была статья с этим решением. Но это не всегда единственный вариант. Сделать можно по-другому.

Пример 2

Жене пришла новая заявка. Он начал искать решение в базе знаний. Безусловно, человек, который заводит заявку, описывает какой-то симптом, по которому он решил, что у него что-то не работает. По этому симптому Женя не нашел решение. Он начал искать новые симптомы, а затем снова обратился к базе знаний. Со второго раза он нашёл статью, применил решение и закрыл заявку. Вместо того, чтобы выискивать решение, во втором случае Женя искал симптомы.

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

На самом деле второй пример описывает очень важный принцип «Ищи раньше, ищи чаще».

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

Что дает такой подход?

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

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

Два этих пункта сильно уменьшили время, которое требовалось новичкам, чтобы стать автономными работниками, с полугода до 2-3 месяцев (в зависимости от входных знаний сотрудника).

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

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

Критерий №4. Только ограниченный круг людей пишет в базу знаний.

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

Пусть статьи пишут только «избранные»

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

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

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

Представьте, что наполнением базы знаний занималось 5 человек. Им нужно было создать плюс-минус 200 статей за неделю и сделать это качественно. А еще актуализировать уже имеющийся стек базы знаний. В нашем случае, на тот момент было 11000 статей.

Здесь возникают сайд-эффекты:

• Проблема приоритизации. То есть, какую статью создавать или актуализировать сейчас, а какую позже?

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

• Потеря экспертизы. Люди, которые записывают знания, но не используют их, быстро теряют техническую экспертизу. Это происходит с любыми чисто теоретическими знаниями.

Последствия… и решения

Первое, что мы сделали — это начали вовлекать всех сотрудников в процесс документирования, это подробно описано в 1 критерии. Но ещё не стоит забывать, что важны знания как джуниора, так и синьора, потому что клиентский уровень тоже разный.

Второй момент, который мы изменили в подходе — начали записывать только те знания, с которыми к нам приходят. Простой принцип:  «нет спроса — нет предложения».

Это позволило решить проблемы связанные с «избранным кругом» для процесса документирования.

Что дает такой подход?

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

Ежегодный опросник показал, что люди стали на 30% более довольны своей работой из-за отмены рутины и уменьшения однообразных задач. То есть, мы ещё снизили вероятность выгорания сотрудников.

Дополнительным эффектом стала поддержка актуальности статей.

Критерий №5. Ни новые фичи, ни фикс багов не улучшают NPS (Net Promoter Score) продукта, либо улучшают незначительно.

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

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

У нас одна и та же статья была в топе по количеству просмотров в течение нескольких месяцев. Она описывала, какие порты необходимо открыть на сервере после установки продукта Plesk.

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

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

Варианты решений

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

Помимо этого, мы смотрели на комментарии к статьям. Люди пишут понравилась им статья или нет, помогла или не помогла, и если не помогла, то почему. Для этого мы использовали приложение Hotjar. Разные аддоны предлагают различный функционал для того, чтобы анализировать статьи и заявки. Также можно прикрутить бесплатный сервис Google Analytics и использовать его.

Мы разобрали 5 критериев, но я решила добавить еще один, потому что считаю его важным. Конечно, логичнее было бы поставить его в начало статьи. Но после разбора всех остальных критериев, начинаешь лучше понимать зачем на самом деле нужна база знаний и что она делает. Становится всё это проще объяснить другим.

Критерий №6. Сотрудники либо топ-менеджмент не понимают, зачем нужна база знаний

Как понять что это происходит? Есть следующие признаки:

• Сотрудники то пишут статьи, то не пишут, но чаще всего принимаются за работу, после пинка руководителя.

• Топ-менеджеры выделяют все меньше ресурсов на развитие базы знаний.

Убеждение топ-менеджмента в том, что вам необходима база знаний — это шаг №0. Он должен быть предпринят еще до начала всей затеи.

Решение: убедите!

Решение на самом деле простое: убедить всех людей, вовлеченных в процесс документирования знаний, что им это нужно! Например, в компании Plesk есть три звена, которые вовлечены в работу с базой знаний:

1. Инженеры технической поддержки;

2. Тимлиды и operations-менеджеры;

3. Директор и вице-президент.

Разберем каждое из них.

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

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

Если говорить о топ-менеджменте, то здесь стоит обратить внимание на метрику ROI (Return On Investment). Она поможет показать, что вложенные в развитие базы знаний средства окупятся. В нашем случае мы предотвратили рост штата технической поддержки на 25%, при том, что наша клиентская база за 2 года выросла на 18%. Несмотря на это, мы смогли плюс-минус сохранить объем заявок, за счет того, что люди сами находили решение своих проблем. Есть прямая зависимость: не растет headcount — не растут затраты на техническую поддержку. Это может убедить топ-менеджеров.

Я дала 6 критериев вместо обещанных 5. Как бы перевыполнила план. Теперь давайте подведем итоги, чтобы это все как-то уложилось.

Подведем итоги

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

• Научите сотрудников работать с базой знаний. Сделайте тренинги. Таким образом вы уменьшите порог вхождения человека в автономный процесс работы. В нашем случае он упал с полугода до 2-3 месяцев.

• Вовлекайте всех сотрудников в процесс документирования. Не важно, джуниор он, синьор или мастер — все знания важны.

• Записывайте все знания, с которыми сталкиваетесь — не бывает знаний, которые не нужны.

• Убедитесь, что все вовлеченные в работу с базой знаний люди понимают ее важность и ценность. Причем важность и ценность именно для них.

• Не пытайтесь думать за клиентов и писать статьи заранее. Предоставляйте знания тогда, когда за ними приходят. Та вы сэкономите время инженеров, и они потратят его на помощь клиентам, развитие своих навыков и участие в других проектах.

• Анализируйте посещаемость статей. Используйте данные анализа для улучшения вашего продукта.

База знаний — это не дополнение к решению проблемы, это и есть метод её решения.

17-18 мая на площадке из двух этажей Крокус-Экспо встретятся 2000 тимлидов и руководителей со своим опытом, инсайтами и энергией. Расписание конференции TeamLead Foundation 2022 уже готово, а купить билеты можно здесь.

Кроме того, от сервиса поиска менторов Getmentor.dev на конференции будут индивидуальные консультации с экспертами. Вы можете принять участие в конкурсе и выиграть 5 часов наставничества. Ментора (или менторов) вы сможете выбрать сами, сейчас в сообществе уже более 500 наставников. Больше информации — по ссылке.

Команда «Онтико» готова помочь тем, кто потерял работу из-за санкций и их последствий. Заполните анкету — и её увидят более 100 потенциальных работодателей. Если у вас есть друзья, которым актуальна помощь, перешлите им это сообщение.