Часть моих публикаций на Хабре была связана с тематикой управления знаниями. Давным-давно (для сферы ИТ 4 года — много) я проводил исследование по управлению знаниями. Тогда собирал информацию с целью выяснить текущее развитие отрасли, собрать опыт пользователей Хабра и набрать материала для публикаций. Был опубликован опрос, собраны результаты и сделаны небольшие выводы . К слову, опрос до сих пор открыт и кто-то иногда даже заполняет анкету.Предметно вопросом управления знаниями я заниматься перестал, но за всё это время получал отклики по опубликованным статьям. Это значит, что тема не угасла, и спустя 4 года я хотел бы добавить в информационное поле рунета дополнительных материалов.
Планирую небольшой цикл статей про KCS — Knowledge Centered Support.
Кому подходит KCS
Если просто, то KCS разработан для компаний, осуществляющих клиентскую и/или техническую поддержку. Если посложнее, то методология при желании адаптируется к предметной области любой компании, в которой встал вопрос сохранения и использования накопленных знаний. Однако, третья буква всё-таки про Support, поэтому сосредоточимся и примеры будем приводить именно с ориентацией на поддержку.
Типичный пример, где KCS пригодится: сотрудник тех.поддержки при поступлении от клиента заявки не знает, как решить проблему, и ему негде посмотреть, решал ли кто-нибудь эту проблему до него, т.е. ему либо приходится переводить заявку на другой уровень поддержки, либо дёргать коллег/начальство.
Вспоминаем, что такое “знание”
Знание не рубль. Со временем определение не меняется, поэтому я просто приведу параграф из прошлой статьи.
Знания — это закономерности предметной области (принципы, связи, законы), полученные в результате практической деятельности и профессионального опыта, позволяющие специалистам ставить и решать задачи в этой области.
Что такое KCS
Если кратко, то KCS — это про процессы, причем про правильно выстроенные процессы. Цель KCS — решить проблему один раз, а затем постоянно использовать найденное решение. По KCS это достигается через создание базы “коллективного опыта” или “базы знаний”. Поэтому и Knowledge Centered Support. Работа поддержки выстраивается таким образом, чтобы было максимальное вовлечение пользователей в базу знаний.
Как же это достигается? Это процесс двойного цикла. Более подробно мы его разберём в следующих статьях. Пока же ограничимся одной картинкой.
Да это очередной маркетинговый термин!
Может быть. Но KCS — это не очередной класс систем по типу ECM, СЭД, EIM и пр. Это методология, разработанная Консорциумом сервисных инноваций. Гиганты индустрии объединились и сообща, не торопясь, с 1992 года отшлифовывали и описывали процессы, как они должно быть в идеале. А софт — о нём мы поговорим в третьей статье — может быть любым, хоть ссылки в Google Docs перелинковывайте.
А вот вам и маркетинговые цифры
По исследованиям самого консорциума, внедрение KCS даёт следующие результаты.
Быстрое решение проблем
- 50-60% сокращение времени решения проблем
- 30-50% увеличение доли решения проблем при первом обращении
Оптимизация использования ресурсов
- 70% сокращение времени выхода на высокий профессиональный уровень
- 20-35% снижение текучки кадров
- 20-40% увеличение удовлетворённости сотрудников
Электронный сервис
- 50% снижение входящей нагрузки(проблемы решаются через веб-самообслуживание)
Организация корпоративного обучения
- 10% снижение входящей нагрузки за счёт устранения причины в продукте
- 20% увеличение доли решения проблем на нижнем уровне поддержки
ITIL и KCS
У меня сразу же после ознакомления с принципами KCS возник вопрос. А как же ITIL, в частности, управление инцидентами по ITIL? Конкурент или нет? Нашёл более-менее авторитетную работу на этот счёт, которая обозначает следующий тезис: KCS дополняет ITIL.
Заключение
Как и любая методология, KCS не является панацеей от всех проблем, возникающих в результате работы службы поддержки, но является хорошим подспорьем для формализации процессов и более слаженной работы.
От читателей хотелось бы получить обратную связь. Встречались ли вы с KCS? Или может с какой-нибудь другой методологией? Как вы считаете, формализация процессов — благо или управляемый хаос лучше? В общем, был бы рад, если бы вы поделились своим опытом.
И напоследок — опрос, как же без него.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (6)
steb
24.10.2015 21:47Комментарий получился сборным, сразу к нескольким упомянутым вами статьям и направленным на порождение диалога.
В начале вы говорили про управление знаниями, дали определение знания. Однако что для вас есть управление вообще, в не зависимости от предметной области?
Дальше было упоминание про набор различных систем-инструментов, в которых знания и информация зачастую используються как синонимы — но всё-же в чём по вашему мнению разница у этих понятий?
И тут-же — инструменты вы упомянули, но они ведь созданы по какой-то идее, яляються следствием некой определённой концепции (скорее всего проросшей из частной предметной области) и вполне ожидаемо что под неё заточены. Отсюда ещё пара вопросов: что для вас концепция и проводилось ли вами выявление и сравнение концепций лежащих у истоков этих инструментов?
Управление знаниями/информацией — это управление чем? Ведь по моему управлять можно только процессами (объектами/явлениями, да ещё и объективно существующими). Например: управлять доступом к информации (кому-то разрешить, кому-то запретить, кого-то уведомить принудительно), управление процессом циркуляции информации, управлять процессом преобразования информации.
И немного ближе к предприятиям и картинкам — НИОКР и профильная деятельность — встречались ли с подобными понятиями, каково отличие процессов циркуляции и преобразования информации в каждом из них? Как они связаны с сетевыми моделями деятельности?
К сожалению пока могу поделиться лишь опытом разбора некоторых понятий и ссылками, по моему близкими к теме:
1. Достаточно общая теория управления
2. Культура административной деятельности
Формализация процессов против управляемого хаоса — интересно что тут имелось в виду. В работе по 1-й ссылке выделены 2 вида управления, структурное — (самый простой пример армия) и безструктурный (тут чуть сложнее, например «сарафанное радио», когда запустив слухи ожидаеться предсказуемый результат). При этом сделана заметка, что структурное выкристализовываеться из безструктурного, при необходимости.
NikMelnikov
27.10.2015 10:48что для вас есть управление вообще, в не зависимости от предметной области?
Разделяю позицию, что управление знаниями — это часть общего управления организацией.
знания и информация зачастую используються как синонимы — но всё-же в чём по вашему мнению разница у этих понятий?
Когда речь идёт об инструментах зачастую да, знания и информация приравниваются к синонимам, но по факту данные понятия нельзя приравнивать. Информация не несёт никакой смысловой или семантической нагрузки. Знания же несут. Определение знания давал выше. Информация же — это просто фактологические данные, без смысловой нагрузки.
И тут-же — инструменты вы упомянули, но они ведь созданы по какой-то идее, яляються следствием некой определённой концепции (скорее всего проросшей из частной предметной области) и вполне ожидаемо что под неё заточены. Отсюда ещё пара вопросов: что для вас концепция и проводилось ли вами выявление и сравнение концепций лежащих у истоков этих инструментов?
Мне кажется, тут дело даже не в концепции, а в решение какой-то проблемы. Вики-системы же появились не просто так. Они решили проблему простого и удобного совместного редактирования документов. Так и любой другой инструмент. Есть проблема, под неё или естественным образом или с помощью маркетологов появляется новый инструмент.
По поводу НИОКРов. Вот там как раз знания и должны выходить на передний план, но это уже наука, тут всё несколько сложнее.
Управление знаниями/информацией — это управление чем?
Вы правильно заметили про процессы. Речь идёт об управлении процессами, которые поддерживают все этапы жизненного цикла знания. Знание же нужно вытащить из чьей-то головы, переписки, кода и т.д., формализовать в каком-то виде для дальнейшего использования и, наконец, использовать повторно. Вот как раз, чтобы все эти процессы работали, и появляется управление знаниями и KCS как один из примеров.
trusted
Слишком не внятно раскрыты истинные преимущества и особенности KCS. В более широком смысле цель методологии KCS это попытка собрать коллективный опыт организации и представить его в доступном виде для всех. То есть KCS это уход от стандартных практик, когда знания компании распространены не равномерно, концентрируются на уровне экспертов.
При том, что эксперты зачастую не хотят делиться знаниями расценивая их как свое конкурентное преимущество.
Кстати вы теоретик или практик?
Изучали первичную документацию KCS Practices Guide и KCS Adoption Guide?
Пытались применить KCS на практике? Если да то каковы успехи, есть чем поделиться?
— Кстати в опросе было бы интересно узнать, кто то использует KCS на практике.
NikMelnikov
Тоже хорошее предложение. Спасибо. Можно сказать, что я специально максимально сузил определение.
Вообще практик, но в другой отрасли. Вопросами же управления знаниями занимался в теоретическом аспекте. На практиков можно попробовать выйти. Поинтересоваться успехами. Но ничего не обещаю. Не все любят делиться своими внутренними процессами.
Да, вторая статья будет выжимкой из как вы говорите из «первичной документации».
Если такие и есть на хабре, то они затаились.
trusted
Просто есть желание и возможность попробовать применить KCS на практике в компании.
Поэтому меня очень интересует реальный опыт.
NikMelnikov
Так дерзайте! Был бы рад, если бы поделились потом опытом. Хоть и процесс не быстрый, но тем не менее.