В каждой техподдержке свои процессы, тикет системы, принципы коммуникации с клиентами. Объединяет эти сервис службы – стремление бороться с пожирателями времени.
Когда в десятый раз за день в рабочем чате видишь «Не помнишь, как по такой заявке лучше ответить?», «Где лежит инструкция?», «Кинь ссылку, не могу найти», а в параллель коллега с порога «Не занят? Мне только спросить», начинаешь взывать к богам, которые хоть что-то слышали про Knowledge Management.
И все чаще мечтаешь не о новом мониторе в 49 дюймов, а о Базе знаний, да лучше с продуманной структурой, удобной навигацией и интеллектуальным поиском. И, пожалуйста, если можно, пусть это будет не склад папок на FTP и не портянка ссылок в Google Docs!
Хранение знаний в головах аналитиков и разработчиков, на стикерах или в закладках браузера – дело обычное. Но с ростом или ротацией команды нет особого желания собрать потенциальные риски от незадокументированных и невыстроенных процессов.
В то же время быть носителем тайных знаний отчасти лестно. При этом не хочется быть замученным вусмерть повторяющимися вопросами. И еще меньше хочется слыть «раздавателем»: погугли сам, спроси там, поищи тут, прочитай здесь.
Поэтому мы в своей поддержке решили собрать весь багаж знаний воедино и попробовать настроить процесс управления знаниями. Делюсь, что из этого вышло и на каком этапе сейчас.
Всем привет, меня зовут Маша. Я – бизнес-аналитик облачного сервис деск решения. Ответить на вопросы, собрать требования, упаковать их в задания и отдать в разработку, помочь с настройками – вот лишь часть моих задач.
Вместе с тем работаю в режиме хронической техподдержки, потому что а) продукт постоянно развивается, б) иной раз что-то идет не так, и вылезают противные баги, в) клиенты регулярно «стучатся» с новыми задачами.
Еще, кроме потоковых дел, есть дежурства. Это когда целый день, как скорая помощь: любой инцидент, сложный запрос клиента, срочные консультации коллег – все летит дежурному аналитику.
Аналитики – это не идеальные роботы. Иногда мы ошибаемся, сомневаемся, как правильно ответить, забываем учесть важное. У нас нет цели вслух повторять документацию по продукту как мантру. Если в вопросе «затык», хочется без труда найти дополнительный источник информации, а не искать час вместо обеда в списке сохраненных закладок.
Как было
Я пришла в команду 3 года назад. Тогда ребята еще не «болели» Базой знаний. Аналитики писали инструкции, складировали их на компьютерах и высылали по запросу.
Изо дня в день приходилось играть в Шерлока Холмса, выясняя, кто автор, где живет документ и актуален ли он.
Устав от просьб «отправьте версию посвежее», попробовали организовать файловое хранилище. Этот способ удобен, когда справочных материалов немного или пользуются ими нечасто.
Наша же команда росла, появлялись новые задачи. Объем инструкций и ответов на типовые
вопросы увеличивался с такой скоростью, как число проданных медицинских масок при эпидемии гриппа.
Тогда решили перекроить процесс: сформировать Базу знаний в одном месте и наполнить ее по-новому.
Еще было важно, чтобы на единой площадке клиенты могли искать ответы на вопросы самостоятельно, без обращения в поддержку. Так хотели снизить наши затраты, что позволило бы уделять больше времени развитию нашего облачного сервис деска.
Какое нашли решение
Сформировали Базу знаний на базе нашей же сервис деск платформы итсм365. Наполняли постепенно.
Первое, что сделали, – разобрались в процессах:
- Кто ответственный.
- Когда пишем статьи.
- Как проверяем.
Второе – ввели в нашей команде три роли: аналитик-куратор, аналитик-автор и аналитик-тестировщик.
Цепочку действий организовали так:
- Командой обсуждаем план на три месяца.
- Куратор ставит задачу автору и тестировщику.
- Автор готовит статью.
- Тестировщик оценивает качество текста, проверяет настройки.
- Куратор говорит статье «да» и публикует ее в Базе знаний.
Каждый аналитик может попробовать себя в разной роли. Не любишь писать, помоги протестировать. Хочешь получить не дежурное «спасибо», когда инструкция написана просто и быстро помогла закрыть инцидент, напросись в авторы.
Еще учитываю загрузку. Вдруг автор статьи занят горящими задачами. Тогда перекидываю задачу на более свободного сотрудника, чтобы успеть выпустить материал до дедлайна.
Чем наполняем Базу знаний
Сейчас я курирую Базу знаний: слежу за публикациями и претендентами на статью. Например, когда выполняю заявку клиента, сразу могу отметить, какой вопрос «дозрел» до новой статьи. Для этого в карточке включаю чекбокс «Претендент на БЗ». Затем мне остается провести мониторинг таких статей и запланировать работы по ним.
При этом в Базу знаний включаю материалы, которые пригодятся и нам, и клиентам.
Внутренние статьи. Сюда размещаю любые полезные материалы для нашей команды аналитиков:
- советы для новичков,
- принципы коммуникации с клиентами,
- типовое решение известной ошибки,
- описание внутренних процессов.
Внешние статьи. С их помощью клиент может разыскать инструкцию сам или получить ответ на свой вопрос без запроса в поддержку. Если заявка зарегистрирована, а у нас в Базе знаний наготове статья, сразу отправим ее клиенту. Как итог – на заявку уходит в разы меньше времени.
Для клиентов чаще пишем:
- ответы на часто задаваемые вопросы,
- инструкции по настройке,
- как запросить работы по обслуживанию и т.п.
Как организуем трансфер знаний
Трансфер статей до клиента реализуем двумя способами.
Отдельный раздел с новинками. Статьи, которые опубликованы за месяц, размещаю на отдельной вкладке. Уже знаю наших постоянных читателей-клиентов, кто следит за обновлениями этого раздела.
Упоминание статей в комментариях. Когда в заявке пишем комментарий, можем тут же сослаться на релевантный материал.
Немного цифр
После запуска в нашей Базе знаний уже 163 статьи, 94 – в претендентах.
457 заявок закрыли, где их решить помогли именно статьи из нашего единого хранилища знаний команды.
В среднем на заявку с готовой инструкцией по настройке мы тратим всего 10 минут. А раньше, чтобы настроить, например, файлы в комментариях уходило около одного часа. В это время суммируем описание настройки по шагам и ответы в заявке на другие смежные вопросы клиента.
Что в итоге
Изначально мы расценивали Базу знаний как задел на будущее: вкладывались временем и ресурсами, поэтапно приучали команду к такой кропотливой и небыстрой работе по наполнению.
Сейчас шаг за шагом движемся к систематизации опыта. В нашу библиотеку собираю все удачные примеры решений, на которые в дальнейшем сможем опираться и использовать в поддержке клиентов. Например, мы поняли, что для определенных кейсов хватает стандартной продуктовой документации, в некоторых случаях лучше подготовить отдельный материал, а где-то шаблонизировать ответы и положить на «полку» Базы знаний поближе.
Все эти усилия и затраты оправдываются результатами. В нашем арсенале двойной бонус: единый источник помогает экономить время команды, быстрее обмениваться знаниями, мгновенно вводить в курс дела новичков. Для нас это удобное хранилище нужной информации, источник готовых ответов, а для клиента – инструмент самостоятельного решения несложных вопросов.
Естественно, что процесс организации идеальной Базы знаний для техподдержки еще не завершен. Постепенно допиливаем разделы, добавляем новые теги для быстрой навигации, совершенствуем структуру. Как только обкатаем новинки на свежих кейсах поддержки, поделюсь успехами с хабровцами.
telobezumnoe
по-моему алгоритмы управления инцидентами проблемами и конфигурациями уже давно весьма известны, но удивляет что до сих пор нет решений на пример в области медицины создание без данных с иерархией полезности методов решения инцидентов, отслеживания проблем,. ведь такие знания уже есть в различных справочниках, и по сути можно использовать для диагностики, подбора анализов для уточнения диагноза, и избежания осложнений
AlexVist
Честно говоря на ваш комментарий могу сказать, что для медицины есть. Еще точнее могу сказать, что есть способ. И был уже давно реализован. Еще в СССР. Еще до компьютеров.
Я сам заимствовал для своей системы именно наработку из медицины. На одном из акселераторов мне сказали, что моя система может называться интераетивной базой знаний. Мне это описание понравилось.
А в общем я писал алгоритм для службы поддержки. так как двигать в медицине нет возможности и сил жалко.)))
Применительно к самой статье могу привести примеры, когда не всегда удается найти решение по похожей проблеме. Так как бывает, что проблема одна, а причины разные. Следовательно, пути решения окажутся другими.
telobezumnoe
так можно несколько решений отображать, и ранжировать их по количеству кому помогло… да и есть управление инцидентами, а есть проблемами, если инцидент повторяется, или инциденты возникают связано, то это переходит в критерий проблемы и решается уже на архитектурном уровне
AlexVist
Мое мнение, что ранжирование вряд ли может помочь. И способы решения проблем могут накопиться в большом количестве.
Применительно к базе знаний. Она должна решать конкретную проблему определенными шагами. но, часто, вы столкнетесь с первичной задачей определения источника проблемы. И уж потом вам понадобятся конкретные шаги по устранению причин.
Я могу привести пример из практики. Пост самообслуживания пациентов. Эт о компьютер с тачскрин экраном, с динамиком, кардридером, принтером, с подключенными к нему весами и измерителем давления. Так же установлено программное обеспечение. Как то что взаимодействует с подключенным оборудованием, так и интерфейс общения с пользователем. Выход из строя чего-либо одного автоматически делает такой пост неработоспособным.
Общее первичное описание проблемы — "Не работает". Само по себе определения того что именно не работает достойно хорошей статьи в базе знаний. Дальше больше. нужно отдельную статью на каждый случай. Случаи так же в себе делятся на различные причины. И так далее. Попытка это отобразить в виде статей имеет громоздкую и неудобную структуру. Иногда поиск займет больше времени, чем нужно реально на устранение.
Я использовал несколько другой подход. Каждый раз сталкиваясь с проблемой в интерактивную базу знаний вносились шаги по диагностике и исправлению. Самый оптимальный вариант. Ведь выводы можно сделать по итогам проведенной работы. и уже после решить что лишнее, а что необходимое. В итоге решение многих проблем превращалось в набор нескольких оптимальных шагов.
Причиной к такому решению стало то, что нужно было обслуживать систему, которая установлена в различных регионах. Уровень специалистов на местах был различным. Заявки люди по одной и той же проблеме заполняли различным образом. часто не собрав необходимой информации. Отвлекались ресурсы более высоких уровней поддержки по вполне уже рутинным вопросам. И всегда можно было отследить по каким шагам прошел специалист по ходу решения.
vasilchenkome
А чем собственно msdmanuals не угодил?
AlexVist
А в чем его преимущество? И я не медик. Мне понравился методологический подход, который смог описать медицину. как по мне одну из самых тяжелых сфер для автоматизации.