Управление знаниями, зачем и как мы это сделали

    Те компании, которые не осознают, что знания являются средством производства более важным, чем земля, труд или капитал, постепенно умрут и никогда не поймут, что их погубило.Ларри Прусак
    Глупость — дар Божий, но злоупотреблять им не следует.Отто фон Бисмарк

    Предисловие


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

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

    • Первое — рассказывать аудитории о своих успехах незачем, поскольку если успехи очевидны для всех — то читатель с тобой будет спорить а не «внимать», если не очевидны — тогда пропустит мимо ушей как спам.
    • Второе — плохой фэншуй побуждать читателя что-либо изменять в «своем королевстве», хороший фэншуй — когда читатель «вызревает», затем ищет своему прозрению решение.
    • Третье — предмет моего рассказа «представляется» хорошо знакомым читателю по временам студенческим, а как и многие знания из того периода — бесполезной тратой времени (если не сказать больше) на практике.
    • Есть и другие причины…

    Получается цель моя сложна, а выгоды не очевидны… В глубине души, сознаюсь, дело еще и в том что мне хочется похвастаться поделится с широкой аудиторией своими, как я считаю, успехами. На habre по моему мнению аудитория подходящая, тем более что никакой «значимой KM тусовочки» пока не сложилось…

    Итак, я решил лучше всего подать материал в двух частях.

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

    Вторая часть — материал в формате дискуссии между мною сегодняшним и мною из 2014 года, когда про управление знаниями я конечно слышал, но по причине №3 никакого значения этому не предавал. Признаю, в этом формате есть что-то «шизофреническое», однако таким беседуя с самим собой мне как-то проще «продавать» аргументы в пользу своих идей.

    Структурно материал организован так:

    • В первых двух коротких главах ответы на вопросы: «о чем» и «кому»;
    • «Теоретическая база» содержится в третьей главе;
    • В четвертой главе «Практическая реализация», очень кратко опыт имплементации KM в нашей организации;
    • Дискуссия со скептиком в предпоследней главе;
    • В заключении, краткое сравнение уровня знаний до и после имплементации KM.

    О чем этот текст


    Этот текст о методике повышения качества и эффективности работы коллектива называемой «Управление знаниями».

    Видя отсутствие специализированных инструментов для управления знаниями, я полагаю, настоящая методика недостаточно применяется в мире и почти не применяется в России.

    Кому этот текст


    По моему скромному мнению, этот текст обязательно нужно прочитать руководителям управляющим коллективом начиная от 7 ± 2 сотрудников.
    Кроме руководителей, изложенная информация может быть любопытна людям профессионально связанным технической поддержкой или HR.

    Теория


    Знания есть информация «усвоенная» (осознанная) человеком или приобретенный человеком опыт. Без человека — не существует знаний. Ведь связи и блат знания, являются предпосылкой для занятия сотрудником определенной позиции внутри организации поскольку должны применяться в процессе исполнения должностных обязанностей.

    Для того чтобы кратко рассказать о управлении общими знаниями в организации прежде зададимся вопросом, что есть организация?

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

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

    Именно необходимость использования человеком (специалистом) знаний, относящихся к «пакету знаний», определенному как минимально-допустимым уровень знаний, определяет в первую очередь должен ли человек быть привлечен в организацию в качестве сотрудника или допустимо использовать аутсорсинг соответствующего специалиста.

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

    Получить общие знания можно двумя методами:

    • традиционное обучение (школа, вуз и тп);
    • KM (управление знаниями).

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

    Основой управления знаниями является идея регулярного использования (тренировки) знаний сотрудниками организации. Регулярное использование знаний достигается посредством применения технологии ситуационного моделирования. Технология ситуационного моделирования содержит сценарии (usecase) применения знаний. Каждый usecase в свою очередь моделирует «практическую« ситуацию в которой сотрудник сталкивается с необходимостью применить знание для разрешения описанной в сценарии ситуации.
    Сценарий состоит из двух частей:

    1. Обучающая часть (знания) — то есть структурированная информация необходимая сотруднику;
    2. Контрольная (вовлекающая, записывающая в память) часть — то есть способ поместить вышеуказанную информацию в память сотрудника.

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

    В ходе ежедневной тренировки знаний сотрудник решает несколько usecase. Результат решения каждого usecase сохраняется. Статистика результатов в конечном счете показывает уровень знаний сотрудника EKi. EKi является хорошим KPi как сотрудника в частности, так и организации в целом.

    Стоит добавить, ежедневно решаемое количество usecase с одной стороны определено минимально приемлемым уровнем знаний, с другой не должно превышает порога «неприятия KM» сотрудника. Повторяемость usecase в процессе KM определяется кривой Эббингауза (Кривая забывания).

    Практическая реализация


    Буду рад ошибиться, но готовых решений, удовлетворяющим в полной мере моим требованиям к имплементации KM, пока не существует. Моя реализация на сегодняшний день это несколько «сторонних» систем, интегрированных между собой:

    • Request Tracker (RT)- движок: база знаний, шаблоны usecase, хранение результатов KM;
    • Google Calendar — расписание обучения: сотрудники, состав usecase сотрудника;
    • Google Spreadsheets — база usecase: тематики, вопросы, ответы;

    Механика взаимодействия систем


    RT используется в качестве системы определяющей логику взаимодействия между системами. Инициатором взаимодействия всегда выступает RT, получая данные запрошенные посредством Google API:

    • Google Calendar отдает перечень сотрудников и количество usecase на сегодня для каждого из них.
    • Google Spreadsheets отдает информацию, необходимую для формирования usecase.
      Кроме этого, RT, используя «скрипы», шаблоны и нотификации, сначала создает и передает usecase каждому сотруднику, а затем проверяет ответы сотрудников.

    Алгоритм тренировки знаний


    Ежедневно, выполняются последовательно следующие процедуры:

    • формируем перечень сотрудников участвующих в тренировке знаний;
    • определяем темы usecase каждому сотруднику;
    • создаем usecase каждому сотруднику в количестве равном количеству тем;
    • передаем usecase сотруднику (email, RT web-interface…);
    • сотрудник в течении рабочего дня должен ответить на вопросы из usecase;
    • проверяем ответы и сохраняем результат проверки каждого usecase.

    Скептику


    Я скептически смотрю на собственные литературные возможности, а поскольку больше всего в жизни я прочитал разных FAQ (но это не точно), именно этот формат я и выбрал для ответов скептически настроенному читателю. Уверен, другая стилистика убедила бы моего читателя еще меньше.

    Вопрос №1


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

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

    Вопрос №2


    Вопрос: OK, пусть так, получается Вы повесили ярлык “управление знаниями” на то что я и без вашего ярлыка делал много лет. Спасибо Вам. А теперь скажите, какая практическая польза от вашего ярлыка?

    Ответ: Вопрос важный, объясню подробно. Вот Вы говорите, что много лет успешно управляете автомобилем. Задумайтесь, действительно ли Вы умеете им управлять, нет ли подмены понятий? Ответьте себе на вопрос — так же ли хорошо Вы будет управлять автомобилем за рулем которого впервые? а если дорога будет «адски» скользкая? а если ехать по узкому серпантину? а если правила дорожного движения отличаются от привычных Вам? Не правильнее-ли сказать Вы отлично справляетесь со «своим авто», в привычной Вам обстановке… Получается, Вы отлично справляетесь с тем, что ежедневно тренируете, а как быть с навыками которые требуются пару раз в год? а один раз в несколько лет? Не правильнее будет утверждать так: я умею управлять машиной, но когда понадобится, приобрету дополнительные специфические навыки по мере необходимости.

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

    Вопрос №3


    Вопрос: «Чего за это х$#я… сложно, сложно бл#$ь … почему так сложно … вообще них#$ не понятно»?

    Ответ: Мда… Короче, если не зашло, объясняю на пальцах. Вы знаете только то что регулярно тренируйте или повторяете, а насчет всего остального — Вы на это уже забили это уже забыли.

    Вопрос №4


    Вопрос: Ну допустим… как из этого извлечь практическую пользу?

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

    Вопрос №5


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

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

    Вопрос №6


    Вопрос: OK, как определить какие знания необходимы?

    Ответ: Вообще-то слишком «широко» поставлен вопрос, но попробую объяснить понятно. Знания есть помещенная в голову информация, а информация есть классифицированные данные. Так вот знаниями должна стать информация, которая должна «отскакивать от зубов» как в известной поговорке. Если приводить аналогии из реалий техподдержки, знаниями должна стать та информация которую инженер должен помнить, а не лезть каждый раз в документацию.

    Вопрос №7


    Вопрос: Повторять регулярно одно и тоже — тупо. Через месяц от этих знаний тошнить будет.

    Ответ: Вы правы, это серьезная проблема. Поэтому нужно подготовить большое количество usecase, чтобы свести к минимуму вероятность «рвотного рефлекса» от повторения одного и того же. Кроме того, методика Эббингауза позволяет повторять usecase, следуя сложному алгоритму, исключающему «рвотные позывы».

    Вопрос №8


    Вопрос: Ясно, понятно — придумал Эббингауз технологию сохранения знаний в голове. Будем справочники учить?

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

    Заключение


    Для повышения «читабельности» текста я исключил много теории и практики. Следствием этого явилось недостаточное полное освещение некоторых тем, а также некоторые тезисы раскрыты не до конца. В частности, важный тезис об эффективности технологии управления знаниями не обрел скалярности / «измеримости». Измеримость уровня знаний сотрудников — есть индекс EKi. EKi является KPI технической поддержки нашей компании. На мой взгляд, таблица ниже полностью раскрывает тезис об эффективности технологии управления знаниями.
    EKi
    декабрь 2016 0,35
    декабрь 2018 0,92
    P.S. Уже перед публикацией от коллег пришла обратная связь «Не понятно с этим EKi. 0.35 это хорошо или плохо? а 0.92 это хуже или лучше в три раза?» … Соглашусь, если сложится — о EKi мой следующий текст.
    Дата-центр «Миран»
    67,00
    Компания
    Поделиться публикацией

    Комментарии 37

      +1
      Хм, неужели я уже успел прокликать по всем ссылкам-заголовкам?
        0
        нужно тренировать только действительно необходимые знания

        Если человек уже какое-то время работает в компании и процесс адаптации завершен, то разве «действительно необходимые знания» не будут у него востребованы постоянно в ходе выполнения своих должностных обязанностей?

        Вообще, «управление знаниями» подразумевает процессы генерации (извлечения) новых знаний, их накопления и последующего эффективного применения. В вашем же случае речь идет об искусственном поддержании некоего уровня предопределенных знаний в головах сотрудников. Возможно, это какая-то специфическая задача для техподдержки — постоянно держать в «активном словаре» знания, которые на практике применяются крайне редко, так что успевают забываться. Мне кажется, что такая система ближе к Learning management system, а не к базе знаний в классическом понимании.
          0
          Знания востребованы с разной частотой. У нас в ТП существуют знания с “периодом востребованности” более шести месяцев (это странно, но это так). При этом, это как раз знания — т.е. время решения соответствующего запроса должно быть минимальным.
            0
            В части генерации новых знаний Вы конечно же правы. У нас знания тоже генерируются, индексируются и сохраняются — просто в тексте я про это не упомянул. Может потом ….

            Про Learning management system — интересная мысль, я подумаю… Вспомнил, Христофор Колумб, он ведь в Индию дорогу искал… а получилось “эвон что”.
            0
            EKi является KPI технической поддержки нашей компании

            За два года этот показатель у вас увеличился почти в три раза. А динамика других KPI техподдержки как-то коррелирует с динамикой EKi? Время реакции, время закрытия заявки, возобновленные заявки, удовлетворенность клиентов?
              0
              EKi не единственный KPI ТП.
              За тот же период (2 года), в числе прочего, я наблюдаю за процентами нарушений времени реакции, времени решения и CSi.
              Придерживаясь принципа научной добросовестности надо сказать так, “математически однозначной” корреляции индексов нет. Однако, если строить “линии тренда”, то рост EKi совпадает с ростом CSi. Проценты нарушений не коррелируют с EKi, но по ним вообще-то отдельный разговор…
              0
              Отличная статья. Автор поднял тему, очень актуальную в повседневной работе инженера. Знания действительно нужно 'тренировать'. А то раз так, приехал на площадку туда, где волки срать боятся, а Гугл там не бывал — и нужно тебе настроить оборудование, а без гугла ты ничего не сделаешь, ибо привык. А если применять методику, изложенную автором — то все будет хорошо. Теперь пожалуйста про индекс EKi. Ждем-с
                +1
                А кто-нибудь считал — сколько стоит управлять знаниями?
                Автор, напишите пожалуйста — сколько человек выделено у вас на КМ на фуллтайм? Сколько времени инженеры и операторы разных уровней заносят в базу новые записи и актуализируют старые?
                Какой профит с этого, в скорости, в деньгах? (его кто-то считал?)

                Я к тому, что в условиях сервисной организации широкого профиля, где набор услуг плюс-минус одинаковый с другими игроками рынка, где инженеры это… расходный часто-меняемый ресурс просто по причине того, что крутого инженера не нужно, нужно пятьдесят «эникейщиков» (я здесь осознанно сильно снижаю квалификацию типового инженера), что любой из этих инженеров держится в компании в среднем полтора года, что тратить ресурс инженера на то чтобы он сидел и забивал «знания» в БД просто экономически не выгодно, потому что мы не растим новых инженеров, мы взаимовыгодно сотрудничаем некоторое время, инженер на наших обьектах учится, мы используя его зарабатываем, когда инженер понимает что стоит больше чем платим ему мы — расстаемся. Вот зачем в таких условиях управлять знаниями?

                Или DevOps — там зачем? Есть цель — создать программный продукт. Набирается команда — архитектор, программисты, тестировщики, техписы и т.п. Архитектор на своем уровне абстракции рисует вижион, ТЗ, ПЗ, детальную спецификацию. Программисты реализуют это в коде, техписы в паралельном режиме создают РА, РП, РпРК, ПиМИ, и десятки других документов, описывающих конкретный продукт. Ни для какого другого продукта этот комплект не подойдет. Весь этот комплект, как из документов проектирования, так и документов эксплуатации — уже есть знания, но они уникальны, как и продукт (да, их частично можно применить где-то еще, но все равно там гигантский уровень переработки).

                Из всего многообразия ИТ я вижу только пару-другую областей, где управление знаниями нужно. Например, колл-центры. Если скорость вхождения оператора в контекст и процесс оказания услуги составляет 1 день — отлично. Если 1 час — великолепно. Если 1 минута которая требуется на вход в соответствующую БД, где есть и знания и алгоритм (дерево) ответов на запросы пользователей — это гениально. И оправдано. Да, в колл-центре надо управлять знаниями, это суть бизнеса колл-центров и операторов первой линии поддержки.
                Еще примеры?

                Заголовок спойлера
                Лет пятнадцать назад написал фантастическую киберпанк-оперу на тему управления знаниями, сейчас отрыл её, если интересно то тыц
                  0
                  Прежде всего, интересные вопросы — спасибо.
                    0
                    В Harvard Business Review была публикация “The Cost of Knowledge”, по мнению авторов почти 17% рабочего времени сотрудников уходит на поиск знаний. Иными словами, это время можно использовать продуктивней если эффективней управлять знаниями. Дальше так, использование указанной в моей статье реализации KM позволяет сотруднику тратить на управление знаниями  примерно 1% рабочего дня. Если пересчитать это через ФОТ, то затраты на KM до 15% от ФОТ рациональны.
                      0
                      У нас правило такое — usecase должен быть закрыт инженером в течении рабочего дня.  На все ежедневные usecase (сейчас это 10 usecase ) уходит чистого времени — минут пять.
                        0
                        Технологически, база usecase пополняется после появления в базе знаний новых документов. Специальных сотрудников на фуллтайме для управления знаниями в нашей компании нет. Документы в базе знаний создают как инженеры ТП так и сотрудники компании из других подразделений.
                          0
                          Я заглянул в статистику, статистические данные не коррелируют с “полутора годами” работы инженера ТП в компании. У нас если инженер продержался первый квартал у него хорошие шансы задержаться в лавке больше трех лет. Внутри ТП есть хорошие перспективы роста и этими перспективами пользуются.
                            0
                            У меня нет экспертизы по KM в R&D, ответить Вам “цифрами” не готов. Из общих соображений, полагаю, эффективность разработки повысится при снижении издержек связанных с недостатком коммуникаций в коллективе (общими знаниями).
                              0
                              Вы правы полагаю, внедрение KM в коллцентрах и на первой линии ТП приносит максимально быстро существенные бенефиты. Насчет всего многообразия ИТ, мой опыт подсказывает внедрение KM целесообразно везде.
                              Почему?
                              Как Вы думаете если сотрудники в компании будут что называется “на одной волне” это повлечет увеличение эффективности работы компании в целом?
                              Мой ответ — да, за счет снижения издержек связанных с недостатком коммуникаций в коллективе (некоторые не знают специфики компании, кто-то не знает как работают коллеги, часть коллег вообще не подозревает о части услуг компании или о их изменении итп).
                              0
                              У нас основной метод управления знаниями — 80/20. 20 процентов своего времени сотрудник должен отдать консультациям коллег. Соответственно, если кто-то сталкивается со сложной задачей, он обязан спросить совета, а респонденты обязаны его дать. Так обеспечивается циркуляция знаний, нужных в момент времени.
                                0
                                В мобильном приложении хабра, увы, нельзя посмотреть, что такое КМ. Расшифруете тут?
                                  0
                                  Пожалуйста, Knowledge Management.
                                  0
                                  Интересно, но реально сложновато. А вот эти usecase — это что? Это какие-то реальные кейсы от юзеров? Или абстрактные, придуманные (кем? кто решает, какой кейс следует включать в ротацию (должность в компании)? на основании чего? сколько времени на составление кейсов тратится?)
                                  Как переводится в деньги тот же CSi?
                                  Если вы говорите, что корреляция между EKi и CSi неочевидна, то, наверное, usecases не совсем коррелируют с реальными потребностями юзеров, которых поддерживает ваша команда.

                                  А еще интересна история с необходимостью помнить много всего. Я сам вырос в КМ из инженера второй линии поддержки. Помню, что есть часто возникающие кейсы, а есть возникающие раз в квартал, но тоже имеющие типовые решения. Прошло 6 лет, и я до сих пор помню алгоритмы решения типовых задач и даже номера статей, которые надо отправлять клиенту по той или иной проблеме. А вот редко встречающиеся кейсы я и тогда смотрел в базе кейсов, и сейчас бы поступил точно так же. Зачем их все время помнить, если они лежат в известном месте, задокументированы и четко описаны? С таким подходом и учу агентов сейчас. На мой взгляд, наиболее важные знания и так из памяти не вылетят, а все остальные нужно уметь найти на корпоративных ресурсах. Базы знаний как раз для того, чтобы найти быстро, а не чтобы агенты в любой момент помнили массу редко всплывающих кейсов.
                                  Может быть, лучше вложиться в нормальное тегирование инструкций в базе и поиск по внутренним ресурсам, а не в удержание в головах агентов большого объема информации?
                                  Имхо, разумеется :) Но, вроде, у меня работает :)
                                    0
                                    Сложновато — упрощаю.
                                      0
                                      Usecase это обезличенные кейсы юзеров или типовые ситуации из реалий техподдержки. Usecase создаются одновременно при создании документов в нашей базе знаний, говоря иначе документ не добавляется в базу знаний без готовых usecase.
                                      Все usecase апрувятся мною.
                                      Что касается времени, то тут все субъективно, мой личный опыт — от 3 до 30 минут.
                                        0
                                        Я говорил иначе, а именно: “если строить “линии тренда”, то рост EKi совпадает с ростом CSi”, таким образом, корреляция линий трендов индексов как минимум есть. Что касается корреляции по месяцам EKi и CSi, то этот вопрос требует отдельного, углубленного изучения. Почему? — потому что период когда пользователь оставляет “обратную связь” не совпадает с периодом управления знаниями инженеров. Однако это совершенно точно за рамками моей статьи.
                                          0
                                          Ситуация, которую я достаточно часто вижу: цель поддержке ставится в метриках, но никто не может ответить, а что дает выполнение этих метрик? Вы вкладываете время = деньги в повышение EKi, имеете достаточно приблизительную корреляцию с CSi на уровне тренда, а вот ваше значение в CSi в деньгах измеримо? Т.е., вы вложили в обучение определенную сумму, получили какой-то эффект на других метриках — можете ли вы посчитать этот эффект в деньгах, чтобы понять, больше ли вы заработали/сэкономили, чем потратили на обучение изначально? Если сумеете ответить на этот вопрос, я очень хочу вашу методику расчета!
                                            0
                                            Э… Изменение метрик влияет на качество работы техподдержки… вроде все просто)
                                            Качество — соответствие ожиданиям. Другое дело связь всегда нелинейная. Иными словами, можно наблюдать корреляцию трендов между ФОТ техподдержки и MTTR например, но однозначно утверждать что увеличение ФОТ на 1% приведет к снижению на 1% MTTR думаю никто серьезно не возьмется.
                                              0
                                              Просто, да не совсем :) Качество — вещь абстрактная. Вот, скажем, у вас уровень удовлетворенности поддержкой — 90%. И что? Что это означает в контексте бизнеса? Что 90% клиентов, столкнувшихся с проблемами и сходивших в техподдержку, продолжат покупать ваш продукт в следующем году, через год, через 10 лет? Или что? Как это самое абстрактное качество посчитать в hard dollars?
                                              Ни в коем случае не критикую подход и позицию, просто очень глубоко погрузился в этот вопрос — интересуюсь с корыстной целью :)
                                                0
                                                Индекс удовлетворенности клиента обслуживанием, показывает бизнесу насколько по мнению клиента то что он получил соответствует его ожиданиям. Этот индекс имеет практический смысл в отношении конкретного тикета. Интерпретация результатов зависит от методики расчета CSi, например у нас индекс больше 0,5 означает что по двум из трех метрик клиент оценил обслуживание как очень хорошее.
                                                Будет ли он продолжать пользоваться услугами нашей компании наверняка сказать нельзя, но можно предположить что возможный “отток” будет связан с чем-то другим…
                                            0
                                            Индекс CSi является KPI техподдержки. Влияние этого индекса на коммерческие KPI (CF, EBITDA итп) походу описывается даже не первой производной функции от многих переменных. Примерно такой же производной можно описать взаимосвязь цены и скорости легкового автомобиля.

                                            Довольно сложно, но все же реально найти объективную взаимосвязь между CSi и коэффициентом оттока клиентов. Если рассматривать отток клиентов как “недополученную прибыль” то вот Вам и методика.
                                          0
                                          Структурированная и индексирована база знаний это прекрасно, думаю несогласных с этим тезисом не найдется.
                                          Но все-же, по моему мнению хорошая техподдержка — это та техподдержка инженеры которой не просят подождать клиента пока они найдут и прочитают документ…
                                          Не убедил? — тогда просто поверьте, есть ситуации когда нужно знать, а не искать.
                                          PS Если Вы скажите — от таких услуг следует отказываться в техподдержке, я вероятно с Вами частично соглашусь, но бизнес — “не согласится”.
                                            0
                                            Больше похоже на маркетинговый лозунг :) Мне кажется, хороша та техподдержка, которая решит проблему клиента :) И если клиент нацелен на конструктив, а не покричать в трубку, то он готов подождать 10 секунд, которые у инженера уйдут на поиск готового и заведомо работающего решения :) Я не знаю, какова структура уровней техподдержки у вас. Может быть, конкретно в вашей компании 10 секунд решают, и это критично для бизнеса. Но большая часть пользователей услуги, за которую они заплатили, стремится, чтобы потраченные ими деньги все же окупались (т.е. починить услугу, чтобы ей можно было дальше пользоваться). Так что, если им вежливо сказать, что «прошу подождать несколько секунд, я предоставлю вам решение (в рамках корпоративного Tone of voice эта фраза может звучать иначе, но суть такая)», то клиент подождет. Лишь бы заработало.
                                            А вот если у агента в голове перемешалось 500 юз-кейсов, и он, отвечая на 80-ый звонок за смену, насоветует клиенту что-нибудь по ошибке, проблем может быть больше :)
                                            Повторюсь, имхо :)
                                              0
                                              Вы правы, решить проблему клиента очень важно, это главный, но это как минимум не единственный KPI техподдержки.
                                              Вероятно, Вы просто не сталкивались с проблемами которые нельзя “гуглить”.
                                                0
                                                О, я не про гугл же :) Про внутренний ресурс, где лежат всякие скрипты, описания проблем с решениями и т.д. :) А если проблема не описана, и ее нельзя нагуглить, то тут и юз-кейсы не помогут. Ведь вы их из реальных кейсов от клиентов собираете, как вы сказали. Тут уже мастерство агента и его понимание поддерживаемого продукта выходят на первый план.
                                                  0
                                                  И я не про гугл ) …
                                                0
                                                Попробую более привести более очевидный пример иллюстрирующий пользу.
                                                Уверен Вам приходилось сталкиваться не только с инцидентами, но и с RFS к примеру.
                                                Представьте существенно изменился регламент выполнения какой-либо часто запрашиваемой операции, а следовательно хорошо знакомой инженерам операции. Инженер о изменении регламента не знает, причина сейчас не важна. Как следствие при выполнении этой операции происходит fuckup. Повезет если этот fuckup сразу себя проявит… а если нет, если ошибки будут накапливать пока не перерастут в инцидент.
                                                Так вот, у нас все изменения регламентов ложатся на usecase, как только инженер выходит на смену — ему волей не волей приходится ознакомится с изменениями.
                                                  0
                                                  Вот это уже интересно :) Осуществлять коммуникацию со сменными инженерами о «новинках», произошедших в другую смену, через работу над юз-кейсами — прямо круто :) А сколько времени выделяется агенту на работу с юз-кейсами в начале смены? Это на рост бэклога никак не влияет? Т.к. это, вроде бы, время не в production.
                                                    0
                                                    Охотно расскажу))
                                                    На ответы у “знающего ”инженера уходит минут пять чистого времени, может несколько больше если каких-то знаний нет. Все ответы, должны быть даны до конца смены.
                                                      0
                                                      Классная практика! лайк :)

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

                                          Самое читаемое