Управление знаниями с KCS
Часть моих публикаций на Хабре была связана с тематикой управления знаниями. Давным-давно (для сферы ИТ 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? Или может с какой-нибудь другой методологией? Как вы считаете, формализация процессов — благо или управляемый хаос лучше? В общем, был бы рад, если бы вы поделились своим опытом.
И напоследок — опрос, как же без него.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
