Те компании, которые не осознают, что знания являются средством производства более важным, чем земля, труд или капитал, постепенно умрут и никогда не поймут, что их погубило.Ларри Прусак
Глупость — дар Божий, но злоупотреблять им не следует.Отто фон Бисмарк
Предисловие
Уже пару лет, в своей ежедневной практике, инженеры технической поддержки нашей компании успешно используют технологию «управление знаниями» KM. При этом, часть коллег до сих пор путает управление знаниями с обучением, совершенно не осознавая разницы между этими технологиями. Этот текст я задумал как некий минимум информации для заинтересованного читателя позволяющий поверхностно разобраться в сути KM и одновременно как аргументацию в пользу KM для скептически настроенного читателя.
Если действительно вдуматься, приходишь к заключению, что написание этого текста — занятие
- Первое — рассказывать аудитории о своих успехах незачем, поскольку если успехи очевидны для всех — то читатель с тобой будет спорить а не «внимать», если не очевидны — тогда пропустит мимо ушей как спам.
- Второе — плохой фэншуй побуждать читателя что-либо изменять в «своем королевстве», хороший фэншуй — когда читатель «вызревает», затем ищет своему прозрению решение.
- Третье — предмет моего рассказа «представляется» хорошо знакомым читателю по временам студенческим, а как и многие знания из того периода — бесполезной тратой времени (если не сказать больше) на практике.
- Есть и другие причины…
Получается цель моя сложна, а выгоды не очевидны… В глубине души, сознаюсь, дело еще и в том что мне хочется
Итак, я решил лучше всего подать материал в двух частях.
Первая часть — максимально простая для понимания, но при этом логически связанная между собой информация по KM.
Вторая часть — материал в формате дискуссии между мною сегодняшним и мною из 2014 года, когда про управление знаниями я конечно слышал, но по причине №3 никакого значения этому не предавал. Признаю, в этом формате есть что-то «шизофреническое», однако таким беседуя с самим собой мне как-то проще «продавать» аргументы в пользу своих идей.
Структурно материал организован так:
- В первых двух коротких главах ответы на вопросы: «о чем» и «кому»;
- «Теоретическая база» содержится в третьей главе;
- В четвертой главе «Практическая реализация», очень кратко опыт имплементации KM в нашей организации;
- Дискуссия со скептиком в предпоследней главе;
- В заключении, краткое сравнение уровня знаний до и после имплементации KM.
О чем этот текст
Этот текст о методике повышения качества и эффективности работы коллектива называемой «Управление знаниями».
Видя отсутствие специализированных инструментов для управления знаниями, я полагаю, настоящая методика недостаточно применяется в мире и почти не применяется в России.
Кому этот текст
По моему скромному мнению, этот текст обязательно нужно прочитать руководителям управляющим коллективом начиная от 7 ± 2 сотрудников.
Кроме руководителей, изложенная информация может быть любопытна людям профессионально связанным технической поддержкой или HR.
Теория
Знания есть информация «усвоенная» (осознанная) человеком или приобретенный человеком опыт. Без человека — не существует знаний. Ведь
Для того чтобы кратко рассказать о управлении общими знаниями в организации прежде зададимся вопросом, что есть организация?
Организация есть группа людей объединенных и координируемых для достижения общей цели или, иначе говоря, миссии организации. Каждый из людей, объединенных в организацию, является специалистом в какой-либо предметной области. Для эффективной коммуникации внутри организации, направленной на выполнение миссии, специалистам необходимы общие знания.
Общими знаниями являются знания, полученные на основании одинаково интерпретируемой и одинаково используемой всеми сотрудниками информации. Соответственно, минимально-допустимым (или минимально приемлемым) уровнем знаний сотрудника организации является такой уровень общих знаний, благодаря которому, сотрудник может эффективно выполнять свои должностные обязанности, взаимодействуя с коллегами и информационными системами организации.
Именно необходимость использования человеком (специалистом) знаний, относящихся к «пакету знаний», определенному как минимально-допустимым уровень знаний, определяет в первую очередь должен ли человек быть привлечен в организацию в качестве сотрудника или допустимо использовать аутсорсинг соответствующего специалиста.
Если вы разделяете мое мнение о важности общих знаний, то вероятно вопрос как «гарантировать» наличие минимально уровня общих знаний в головах сотрудников либо уже пришел, либо скоро придет вам в голову.
Получить общие знания можно двумя методами:
- традиционное обучение (школа, вуз и тп);
- KM (управление знаниями).
На рассказ про традиционное обучение я ваше время тратить не стану, тем более традиционное обучение не дает гарантии сохранения редко используемых знаний в голове, далее про KM.
Основой управления знаниями является идея регулярного использования (тренировки) знаний сотрудниками организации. Регулярное использование знаний достигается посредством применения технологии ситуационного моделирования. Технология ситуационного моделирования содержит сценарии (usecase) применения знаний. Каждый usecase в свою очередь моделирует «практическую« ситуацию в которой сотрудник сталкивается с необходимостью применить знание для разрешения описанной в сценарии ситуации.
Сценарий состоит из двух частей:
- Обучающая часть (знания) — то есть структурированная информация необходимая сотруднику;
- Контрольная (вовлекающая, записывающая в память) часть — то есть способ поместить вышеуказанную информацию в память сотрудника.
Обе части 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 |
Комментарии (18)
reki
18.02.2019 17:23нужно тренировать только действительно необходимые знания
Если человек уже какое-то время работает в компании и процесс адаптации завершен, то разве «действительно необходимые знания» не будут у него востребованы постоянно в ходе выполнения своих должностных обязанностей?
Вообще, «управление знаниями» подразумевает процессы генерации (извлечения) новых знаний, их накопления и последующего эффективного применения. В вашем же случае речь идет об искусственном поддержании некоего уровня предопределенных знаний в головах сотрудников. Возможно, это какая-то специфическая задача для техподдержки — постоянно держать в «активном словаре» знания, которые на практике применяются крайне редко, так что успевают забываться. Мне кажется, что такая система ближе к Learning management system, а не к базе знаний в классическом понимании.ASol Автор
18.02.2019 18:48Знания востребованы с разной частотой. У нас в ТП существуют знания с “периодом востребованности” более шести месяцев (это странно, но это так). При этом, это как раз знания — т.е. время решения соответствующего запроса должно быть минимальным.
ASol Автор
18.02.2019 19:00В части генерации новых знаний Вы конечно же правы. У нас знания тоже генерируются, индексируются и сохраняются — просто в тексте я про это не упомянул. Может потом ….
Про Learning management system — интересная мысль, я подумаю… Вспомнил, Христофор Колумб, он ведь в Индию дорогу искал… а получилось “эвон что”.
reki
18.02.2019 17:41EKi является KPI технической поддержки нашей компании
За два года этот показатель у вас увеличился почти в три раза. А динамика других KPI техподдержки как-то коррелирует с динамикой EKi? Время реакции, время закрытия заявки, возобновленные заявки, удовлетворенность клиентов?ASol Автор
18.02.2019 18:44EKi не единственный KPI ТП.
За тот же период (2 года), в числе прочего, я наблюдаю за процентами нарушений времени реакции, времени решения и CSi.
Придерживаясь принципа научной добросовестности надо сказать так, “математически однозначной” корреляции индексов нет. Однако, если строить “линии тренда”, то рост EKi совпадает с ростом CSi. Проценты нарушений не коррелируют с EKi, но по ним вообще-то отдельный разговор…
Vvka
18.02.2019 18:33Отличная статья. Автор поднял тему, очень актуальную в повседневной работе инженера. Знания действительно нужно 'тренировать'. А то раз так, приехал на площадку туда, где волки срать боятся, а Гугл там не бывал — и нужно тебе настроить оборудование, а без гугла ты ничего не сделаешь, ибо привык. А если применять методику, изложенную автором — то все будет хорошо. Теперь пожалуйста про индекс EKi. Ждем-с
kagarich
18.02.2019 19:03+1А кто-нибудь считал — сколько стоит управлять знаниями?
Автор, напишите пожалуйста — сколько человек выделено у вас на КМ на фуллтайм? Сколько времени инженеры и операторы разных уровней заносят в базу новые записи и актуализируют старые?
Какой профит с этого, в скорости, в деньгах? (его кто-то считал?)
Я к тому, что в условиях сервисной организации широкого профиля, где набор услуг плюс-минус одинаковый с другими игроками рынка, где инженеры это…расходныйчасто-меняемый ресурс просто по причине того, что крутого инженера не нужно, нужно пятьдесят «эникейщиков» (я здесь осознанно сильно снижаю квалификацию типового инженера), что любой из этих инженеров держится в компании в среднем полтора года, что тратить ресурс инженера на то чтобы он сидел и забивал «знания» в БД просто экономически не выгодно, потому что мы не растим новых инженеров, мы взаимовыгодно сотрудничаем некоторое время, инженер на наших обьектах учится, мы используя его зарабатываем, когда инженер понимает что стоит больше чем платим ему мы — расстаемся. Вот зачем в таких условиях управлять знаниями?
Или DevOps — там зачем? Есть цель — создать программный продукт. Набирается команда — архитектор, программисты, тестировщики, техписы и т.п. Архитектор на своем уровне абстракции рисует вижион, ТЗ, ПЗ, детальную спецификацию. Программисты реализуют это в коде, техписы в паралельном режиме создают РА, РП, РпРК, ПиМИ, и десятки других документов, описывающих конкретный продукт. Ни для какого другого продукта этот комплект не подойдет. Весь этот комплект, как из документов проектирования, так и документов эксплуатации — уже есть знания, но они уникальны, как и продукт (да, их частично можно применить где-то еще, но все равно там гигантский уровень переработки).
Из всего многообразия ИТ я вижу только пару-другую областей, где управление знаниями нужно. Например, колл-центры. Если скорость вхождения оператора в контекст и процесс оказания услуги составляет 1 день — отлично. Если 1 час — великолепно. Если 1 минута которая требуется на вход в соответствующую БД, где есть и знания и алгоритм (дерево) ответов на запросы пользователей — это гениально. И оправдано. Да, в колл-центре надо управлять знаниями, это суть бизнеса колл-центров и операторов первой линии поддержки.
Еще примеры?
Заголовок спойлераЛет пятнадцать назад написал фантастическую киберпанк-оперу на тему управления знаниями, сейчас отрыл её, если интересно то тыцASol Автор
19.02.2019 07:51В Harvard Business Review была публикация “The Cost of Knowledge”, по мнению авторов почти 17% рабочего времени сотрудников уходит на поиск знаний. Иными словами, это время можно использовать продуктивней если эффективней управлять знаниями. Дальше так, использование указанной в моей статье реализации KM позволяет сотруднику тратить на управление знаниями примерно 1% рабочего дня. Если пересчитать это через ФОТ, то затраты на KM до 15% от ФОТ рациональны.
ASol Автор
19.02.2019 07:52У нас правило такое — usecase должен быть закрыт инженером в течении рабочего дня. На все ежедневные usecase (сейчас это 10 usecase ) уходит чистого времени — минут пять.
ASol Автор
19.02.2019 07:52Технологически, база usecase пополняется после появления в базе знаний новых документов. Специальных сотрудников на фуллтайме для управления знаниями в нашей компании нет. Документы в базе знаний создают как инженеры ТП так и сотрудники компании из других подразделений.
ASol Автор
19.02.2019 07:53Я заглянул в статистику, статистические данные не коррелируют с “полутора годами” работы инженера ТП в компании. У нас если инженер продержался первый квартал у него хорошие шансы задержаться в лавке больше трех лет. Внутри ТП есть хорошие перспективы роста и этими перспективами пользуются.
ASol Автор
19.02.2019 07:53У меня нет экспертизы по KM в R&D, ответить Вам “цифрами” не готов. Из общих соображений, полагаю, эффективность разработки повысится при снижении издержек связанных с недостатком коммуникаций в коллективе (общими знаниями).
ASol Автор
19.02.2019 07:54Вы правы полагаю, внедрение KM в коллцентрах и на первой линии ТП приносит максимально быстро существенные бенефиты. Насчет всего многообразия ИТ, мой опыт подсказывает внедрение KM целесообразно везде.
Почему?
Как Вы думаете если сотрудники в компании будут что называется “на одной волне” это повлечет увеличение эффективности работы компании в целом?
Мой ответ — да, за счет снижения издержек связанных с недостатком коммуникаций в коллективе (некоторые не знают специфики компании, кто-то не знает как работают коллеги, часть коллег вообще не подозревает о части услуг компании или о их изменении итп).
reinvent
18.02.2019 20:57У нас основной метод управления знаниями — 80/20. 20 процентов своего времени сотрудник должен отдать консультациям коллег. Соответственно, если кто-то сталкивается со сложной задачей, он обязан спросить совета, а респонденты обязаны его дать. Так обеспечивается циркуляция знаний, нужных в момент времени.
fenst
Хм, неужели я уже успел прокликать по всем ссылкам-заголовкам?