Комментарии 37
Хм, неужели я уже успел прокликать по всем ссылкам-заголовкам?
нужно тренировать только действительно необходимые знания
Если человек уже какое-то время работает в компании и процесс адаптации завершен, то разве «действительно необходимые знания» не будут у него востребованы постоянно в ходе выполнения своих должностных обязанностей?
Вообще, «управление знаниями» подразумевает процессы генерации (извлечения) новых знаний, их накопления и последующего эффективного применения. В вашем же случае речь идет об искусственном поддержании некоего уровня предопределенных знаний в головах сотрудников. Возможно, это какая-то специфическая задача для техподдержки — постоянно держать в «активном словаре» знания, которые на практике применяются крайне редко, так что успевают забываться. Мне кажется, что такая система ближе к Learning management system, а не к базе знаний в классическом понимании.
Знания востребованы с разной частотой. У нас в ТП существуют знания с “периодом востребованности” более шести месяцев (это странно, но это так). При этом, это как раз знания — т.е. время решения соответствующего запроса должно быть минимальным.
В части генерации новых знаний Вы конечно же правы. У нас знания тоже генерируются, индексируются и сохраняются — просто в тексте я про это не упомянул. Может потом ….
Про Learning management system — интересная мысль, я подумаю… Вспомнил, Христофор Колумб, он ведь в Индию дорогу искал… а получилось “эвон что”.
Про Learning management system — интересная мысль, я подумаю… Вспомнил, Христофор Колумб, он ведь в Индию дорогу искал… а получилось “эвон что”.
EKi является KPI технической поддержки нашей компании
За два года этот показатель у вас увеличился почти в три раза. А динамика других KPI техподдержки как-то коррелирует с динамикой EKi? Время реакции, время закрытия заявки, возобновленные заявки, удовлетворенность клиентов?
EKi не единственный KPI ТП.
За тот же период (2 года), в числе прочего, я наблюдаю за процентами нарушений времени реакции, времени решения и CSi.
Придерживаясь принципа научной добросовестности надо сказать так, “математически однозначной” корреляции индексов нет. Однако, если строить “линии тренда”, то рост EKi совпадает с ростом CSi. Проценты нарушений не коррелируют с EKi, но по ним вообще-то отдельный разговор…
За тот же период (2 года), в числе прочего, я наблюдаю за процентами нарушений времени реакции, времени решения и CSi.
Придерживаясь принципа научной добросовестности надо сказать так, “математически однозначной” корреляции индексов нет. Однако, если строить “линии тренда”, то рост EKi совпадает с ростом CSi. Проценты нарушений не коррелируют с EKi, но по ним вообще-то отдельный разговор…
Отличная статья. Автор поднял тему, очень актуальную в повседневной работе инженера. Знания действительно нужно 'тренировать'. А то раз так, приехал на площадку туда, где волки срать боятся, а Гугл там не бывал — и нужно тебе настроить оборудование, а без гугла ты ничего не сделаешь, ибо привык. А если применять методику, изложенную автором — то все будет хорошо. Теперь пожалуйста про индекс EKi. Ждем-с
А кто-нибудь считал — сколько стоит управлять знаниями?
Автор, напишите пожалуйста — сколько человек выделено у вас на КМ на фуллтайм? Сколько времени инженеры и операторы разных уровней заносят в базу новые записи и актуализируют старые?
Какой профит с этого, в скорости, в деньгах? (его кто-то считал?)
Я к тому, что в условиях сервисной организации широкого профиля, где набор услуг плюс-минус одинаковый с другими игроками рынка, где инженеры это…расходный часто-меняемый ресурс просто по причине того, что крутого инженера не нужно, нужно пятьдесят «эникейщиков» (я здесь осознанно сильно снижаю квалификацию типового инженера), что любой из этих инженеров держится в компании в среднем полтора года, что тратить ресурс инженера на то чтобы он сидел и забивал «знания» в БД просто экономически не выгодно, потому что мы не растим новых инженеров, мы взаимовыгодно сотрудничаем некоторое время, инженер на наших обьектах учится, мы используя его зарабатываем, когда инженер понимает что стоит больше чем платим ему мы — расстаемся. Вот зачем в таких условиях управлять знаниями?
Или DevOps — там зачем? Есть цель — создать программный продукт. Набирается команда — архитектор, программисты, тестировщики, техписы и т.п. Архитектор на своем уровне абстракции рисует вижион, ТЗ, ПЗ, детальную спецификацию. Программисты реализуют это в коде, техписы в паралельном режиме создают РА, РП, РпРК, ПиМИ, и десятки других документов, описывающих конкретный продукт. Ни для какого другого продукта этот комплект не подойдет. Весь этот комплект, как из документов проектирования, так и документов эксплуатации — уже есть знания, но они уникальны, как и продукт (да, их частично можно применить где-то еще, но все равно там гигантский уровень переработки).
Из всего многообразия ИТ я вижу только пару-другую областей, где управление знаниями нужно. Например, колл-центры. Если скорость вхождения оператора в контекст и процесс оказания услуги составляет 1 день — отлично. Если 1 час — великолепно. Если 1 минута которая требуется на вход в соответствующую БД, где есть и знания и алгоритм (дерево) ответов на запросы пользователей — это гениально. И оправдано. Да, в колл-центре надо управлять знаниями, это суть бизнеса колл-центров и операторов первой линии поддержки.
Еще примеры?
Автор, напишите пожалуйста — сколько человек выделено у вас на КМ на фуллтайм? Сколько времени инженеры и операторы разных уровней заносят в базу новые записи и актуализируют старые?
Какой профит с этого, в скорости, в деньгах? (его кто-то считал?)
Я к тому, что в условиях сервисной организации широкого профиля, где набор услуг плюс-минус одинаковый с другими игроками рынка, где инженеры это…
Или DevOps — там зачем? Есть цель — создать программный продукт. Набирается команда — архитектор, программисты, тестировщики, техписы и т.п. Архитектор на своем уровне абстракции рисует вижион, ТЗ, ПЗ, детальную спецификацию. Программисты реализуют это в коде, техписы в паралельном режиме создают РА, РП, РпРК, ПиМИ, и десятки других документов, описывающих конкретный продукт. Ни для какого другого продукта этот комплект не подойдет. Весь этот комплект, как из документов проектирования, так и документов эксплуатации — уже есть знания, но они уникальны, как и продукт (да, их частично можно применить где-то еще, но все равно там гигантский уровень переработки).
Из всего многообразия ИТ я вижу только пару-другую областей, где управление знаниями нужно. Например, колл-центры. Если скорость вхождения оператора в контекст и процесс оказания услуги составляет 1 день — отлично. Если 1 час — великолепно. Если 1 минута которая требуется на вход в соответствующую БД, где есть и знания и алгоритм (дерево) ответов на запросы пользователей — это гениально. И оправдано. Да, в колл-центре надо управлять знаниями, это суть бизнеса колл-центров и операторов первой линии поддержки.
Еще примеры?
Заголовок спойлера
Лет пятнадцать назад написал фантастическую киберпанк-оперу на тему управления знаниями, сейчас отрыл её, если интересно то тыц
Прежде всего, интересные вопросы — спасибо.
В Harvard Business Review была публикация “The Cost of Knowledge”, по мнению авторов почти 17% рабочего времени сотрудников уходит на поиск знаний. Иными словами, это время можно использовать продуктивней если эффективней управлять знаниями. Дальше так, использование указанной в моей статье реализации KM позволяет сотруднику тратить на управление знаниями примерно 1% рабочего дня. Если пересчитать это через ФОТ, то затраты на KM до 15% от ФОТ рациональны.
У нас правило такое — usecase должен быть закрыт инженером в течении рабочего дня. На все ежедневные usecase (сейчас это 10 usecase ) уходит чистого времени — минут пять.
Технологически, база usecase пополняется после появления в базе знаний новых документов. Специальных сотрудников на фуллтайме для управления знаниями в нашей компании нет. Документы в базе знаний создают как инженеры ТП так и сотрудники компании из других подразделений.
Я заглянул в статистику, статистические данные не коррелируют с “полутора годами” работы инженера ТП в компании. У нас если инженер продержался первый квартал у него хорошие шансы задержаться в лавке больше трех лет. Внутри ТП есть хорошие перспективы роста и этими перспективами пользуются.
У меня нет экспертизы по KM в R&D, ответить Вам “цифрами” не готов. Из общих соображений, полагаю, эффективность разработки повысится при снижении издержек связанных с недостатком коммуникаций в коллективе (общими знаниями).
Вы правы полагаю, внедрение KM в коллцентрах и на первой линии ТП приносит максимально быстро существенные бенефиты. Насчет всего многообразия ИТ, мой опыт подсказывает внедрение KM целесообразно везде.
Почему?
Как Вы думаете если сотрудники в компании будут что называется “на одной волне” это повлечет увеличение эффективности работы компании в целом?
Мой ответ — да, за счет снижения издержек связанных с недостатком коммуникаций в коллективе (некоторые не знают специфики компании, кто-то не знает как работают коллеги, часть коллег вообще не подозревает о части услуг компании или о их изменении итп).
Почему?
Как Вы думаете если сотрудники в компании будут что называется “на одной волне” это повлечет увеличение эффективности работы компании в целом?
Мой ответ — да, за счет снижения издержек связанных с недостатком коммуникаций в коллективе (некоторые не знают специфики компании, кто-то не знает как работают коллеги, часть коллег вообще не подозревает о части услуг компании или о их изменении итп).
У нас основной метод управления знаниями — 80/20. 20 процентов своего времени сотрудник должен отдать консультациям коллег. Соответственно, если кто-то сталкивается со сложной задачей, он обязан спросить совета, а респонденты обязаны его дать. Так обеспечивается циркуляция знаний, нужных в момент времени.
В мобильном приложении хабра, увы, нельзя посмотреть, что такое КМ. Расшифруете тут?
Интересно, но реально сложновато. А вот эти usecase — это что? Это какие-то реальные кейсы от юзеров? Или абстрактные, придуманные (кем? кто решает, какой кейс следует включать в ротацию (должность в компании)? на основании чего? сколько времени на составление кейсов тратится?)
Как переводится в деньги тот же CSi?
Если вы говорите, что корреляция между EKi и CSi неочевидна, то, наверное, usecases не совсем коррелируют с реальными потребностями юзеров, которых поддерживает ваша команда.
А еще интересна история с необходимостью помнить много всего. Я сам вырос в КМ из инженера второй линии поддержки. Помню, что есть часто возникающие кейсы, а есть возникающие раз в квартал, но тоже имеющие типовые решения. Прошло 6 лет, и я до сих пор помню алгоритмы решения типовых задач и даже номера статей, которые надо отправлять клиенту по той или иной проблеме. А вот редко встречающиеся кейсы я и тогда смотрел в базе кейсов, и сейчас бы поступил точно так же. Зачем их все время помнить, если они лежат в известном месте, задокументированы и четко описаны? С таким подходом и учу агентов сейчас. На мой взгляд, наиболее важные знания и так из памяти не вылетят, а все остальные нужно уметь найти на корпоративных ресурсах. Базы знаний как раз для того, чтобы найти быстро, а не чтобы агенты в любой момент помнили массу редко всплывающих кейсов.
Может быть, лучше вложиться в нормальное тегирование инструкций в базе и поиск по внутренним ресурсам, а не в удержание в головах агентов большого объема информации?
Имхо, разумеется :) Но, вроде, у меня работает :)
Как переводится в деньги тот же CSi?
Если вы говорите, что корреляция между EKi и CSi неочевидна, то, наверное, usecases не совсем коррелируют с реальными потребностями юзеров, которых поддерживает ваша команда.
А еще интересна история с необходимостью помнить много всего. Я сам вырос в КМ из инженера второй линии поддержки. Помню, что есть часто возникающие кейсы, а есть возникающие раз в квартал, но тоже имеющие типовые решения. Прошло 6 лет, и я до сих пор помню алгоритмы решения типовых задач и даже номера статей, которые надо отправлять клиенту по той или иной проблеме. А вот редко встречающиеся кейсы я и тогда смотрел в базе кейсов, и сейчас бы поступил точно так же. Зачем их все время помнить, если они лежат в известном месте, задокументированы и четко описаны? С таким подходом и учу агентов сейчас. На мой взгляд, наиболее важные знания и так из памяти не вылетят, а все остальные нужно уметь найти на корпоративных ресурсах. Базы знаний как раз для того, чтобы найти быстро, а не чтобы агенты в любой момент помнили массу редко всплывающих кейсов.
Может быть, лучше вложиться в нормальное тегирование инструкций в базе и поиск по внутренним ресурсам, а не в удержание в головах агентов большого объема информации?
Имхо, разумеется :) Но, вроде, у меня работает :)
Сложновато — упрощаю.
Usecase это обезличенные кейсы юзеров или типовые ситуации из реалий техподдержки. Usecase создаются одновременно при создании документов в нашей базе знаний, говоря иначе документ не добавляется в базу знаний без готовых usecase.
Все usecase апрувятся мною.
Что касается времени, то тут все субъективно, мой личный опыт — от 3 до 30 минут.
Все usecase апрувятся мною.
Что касается времени, то тут все субъективно, мой личный опыт — от 3 до 30 минут.
Я говорил иначе, а именно: “если строить “линии тренда”, то рост EKi совпадает с ростом CSi”, таким образом, корреляция линий трендов индексов как минимум есть. Что касается корреляции по месяцам EKi и CSi, то этот вопрос требует отдельного, углубленного изучения. Почему? — потому что период когда пользователь оставляет “обратную связь” не совпадает с периодом управления знаниями инженеров. Однако это совершенно точно за рамками моей статьи.
Ситуация, которую я достаточно часто вижу: цель поддержке ставится в метриках, но никто не может ответить, а что дает выполнение этих метрик? Вы вкладываете время = деньги в повышение EKi, имеете достаточно приблизительную корреляцию с CSi на уровне тренда, а вот ваше значение в CSi в деньгах измеримо? Т.е., вы вложили в обучение определенную сумму, получили какой-то эффект на других метриках — можете ли вы посчитать этот эффект в деньгах, чтобы понять, больше ли вы заработали/сэкономили, чем потратили на обучение изначально? Если сумеете ответить на этот вопрос, я очень хочу вашу методику расчета!
Э… Изменение метрик влияет на качество работы техподдержки… вроде все просто)
Качество — соответствие ожиданиям. Другое дело связь всегда нелинейная. Иными словами, можно наблюдать корреляцию трендов между ФОТ техподдержки и MTTR например, но однозначно утверждать что увеличение ФОТ на 1% приведет к снижению на 1% MTTR думаю никто серьезно не возьмется.
Качество — соответствие ожиданиям. Другое дело связь всегда нелинейная. Иными словами, можно наблюдать корреляцию трендов между ФОТ техподдержки и MTTR например, но однозначно утверждать что увеличение ФОТ на 1% приведет к снижению на 1% MTTR думаю никто серьезно не возьмется.
Просто, да не совсем :) Качество — вещь абстрактная. Вот, скажем, у вас уровень удовлетворенности поддержкой — 90%. И что? Что это означает в контексте бизнеса? Что 90% клиентов, столкнувшихся с проблемами и сходивших в техподдержку, продолжат покупать ваш продукт в следующем году, через год, через 10 лет? Или что? Как это самое абстрактное качество посчитать в hard dollars?
Ни в коем случае не критикую подход и позицию, просто очень глубоко погрузился в этот вопрос — интересуюсь с корыстной целью :)
Ни в коем случае не критикую подход и позицию, просто очень глубоко погрузился в этот вопрос — интересуюсь с корыстной целью :)
Индекс удовлетворенности клиента обслуживанием, показывает бизнесу насколько по мнению клиента то что он получил соответствует его ожиданиям. Этот индекс имеет практический смысл в отношении конкретного тикета. Интерпретация результатов зависит от методики расчета CSi, например у нас индекс больше 0,5 означает что по двум из трех метрик клиент оценил обслуживание как очень хорошее.
Будет ли он продолжать пользоваться услугами нашей компании наверняка сказать нельзя, но можно предположить что возможный “отток” будет связан с чем-то другим…
Будет ли он продолжать пользоваться услугами нашей компании наверняка сказать нельзя, но можно предположить что возможный “отток” будет связан с чем-то другим…
Индекс CSi является KPI техподдержки. Влияние этого индекса на коммерческие KPI (CF, EBITDA итп) походу описывается даже не первой производной функции от многих переменных. Примерно такой же производной можно описать взаимосвязь цены и скорости легкового автомобиля.
Довольно сложно, но все же реально найти объективную взаимосвязь между CSi и коэффициентом оттока клиентов. Если рассматривать отток клиентов как “недополученную прибыль” то вот Вам и методика.
Довольно сложно, но все же реально найти объективную взаимосвязь между CSi и коэффициентом оттока клиентов. Если рассматривать отток клиентов как “недополученную прибыль” то вот Вам и методика.
Структурированная и индексирована база знаний это прекрасно, думаю несогласных с этим тезисом не найдется.
Но все-же, по моему мнению хорошая техподдержка — это та техподдержка инженеры которой не просят подождать клиента пока они найдут и прочитают документ…
Не убедил? — тогда просто поверьте, есть ситуации когда нужно знать, а не искать.
PS Если Вы скажите — от таких услуг следует отказываться в техподдержке, я вероятно с Вами частично соглашусь, но бизнес — “не согласится”.
Но все-же, по моему мнению хорошая техподдержка — это та техподдержка инженеры которой не просят подождать клиента пока они найдут и прочитают документ…
Не убедил? — тогда просто поверьте, есть ситуации когда нужно знать, а не искать.
PS Если Вы скажите — от таких услуг следует отказываться в техподдержке, я вероятно с Вами частично соглашусь, но бизнес — “не согласится”.
Больше похоже на маркетинговый лозунг :) Мне кажется, хороша та техподдержка, которая решит проблему клиента :) И если клиент нацелен на конструктив, а не покричать в трубку, то он готов подождать 10 секунд, которые у инженера уйдут на поиск готового и заведомо работающего решения :) Я не знаю, какова структура уровней техподдержки у вас. Может быть, конкретно в вашей компании 10 секунд решают, и это критично для бизнеса. Но большая часть пользователей услуги, за которую они заплатили, стремится, чтобы потраченные ими деньги все же окупались (т.е. починить услугу, чтобы ей можно было дальше пользоваться). Так что, если им вежливо сказать, что «прошу подождать несколько секунд, я предоставлю вам решение (в рамках корпоративного Tone of voice эта фраза может звучать иначе, но суть такая)», то клиент подождет. Лишь бы заработало.
А вот если у агента в голове перемешалось 500 юз-кейсов, и он, отвечая на 80-ый звонок за смену, насоветует клиенту что-нибудь по ошибке, проблем может быть больше :)
Повторюсь, имхо :)
А вот если у агента в голове перемешалось 500 юз-кейсов, и он, отвечая на 80-ый звонок за смену, насоветует клиенту что-нибудь по ошибке, проблем может быть больше :)
Повторюсь, имхо :)
Вы правы, решить проблему клиента очень важно, это главный, но это как минимум не единственный KPI техподдержки.
Вероятно, Вы просто не сталкивались с проблемами которые нельзя “гуглить”.
Вероятно, Вы просто не сталкивались с проблемами которые нельзя “гуглить”.
О, я не про гугл же :) Про внутренний ресурс, где лежат всякие скрипты, описания проблем с решениями и т.д. :) А если проблема не описана, и ее нельзя нагуглить, то тут и юз-кейсы не помогут. Ведь вы их из реальных кейсов от клиентов собираете, как вы сказали. Тут уже мастерство агента и его понимание поддерживаемого продукта выходят на первый план.
Попробую более привести более очевидный пример иллюстрирующий пользу.
Уверен Вам приходилось сталкиваться не только с инцидентами, но и с RFS к примеру.
Представьте существенно изменился регламент выполнения какой-либо часто запрашиваемой операции, а следовательно хорошо знакомой инженерам операции. Инженер о изменении регламента не знает, причина сейчас не важна. Как следствие при выполнении этой операции происходит fuckup. Повезет если этот fuckup сразу себя проявит… а если нет, если ошибки будут накапливать пока не перерастут в инцидент.
Так вот, у нас все изменения регламентов ложатся на usecase, как только инженер выходит на смену — ему волей не волей приходится ознакомится с изменениями.
Уверен Вам приходилось сталкиваться не только с инцидентами, но и с RFS к примеру.
Представьте существенно изменился регламент выполнения какой-либо часто запрашиваемой операции, а следовательно хорошо знакомой инженерам операции. Инженер о изменении регламента не знает, причина сейчас не важна. Как следствие при выполнении этой операции происходит fuckup. Повезет если этот fuckup сразу себя проявит… а если нет, если ошибки будут накапливать пока не перерастут в инцидент.
Так вот, у нас все изменения регламентов ложатся на usecase, как только инженер выходит на смену — ему волей не волей приходится ознакомится с изменениями.
Вот это уже интересно :) Осуществлять коммуникацию со сменными инженерами о «новинках», произошедших в другую смену, через работу над юз-кейсами — прямо круто :) А сколько времени выделяется агенту на работу с юз-кейсами в начале смены? Это на рост бэклога никак не влияет? Т.к. это, вроде бы, время не в production.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Управление знаниями, зачем и как мы это сделали