В предыдущем материале я начал тему с управлением знаниями. В нём я сформулировал три основные задачи, которые решают организации в рамках управления знаниями: сбор, хранение и распространение. Так как тут у меня блог про IT, хочу поговорить про хранение и распространение – а именно про базы знаний. Это всё же больше в зоне управления служб IT.
Википедия даёт следующее определение: «База знаний – это база данных, содержащая правила вывода и информацию о человеческом опыте и знаниях в некоторой предметной области». В контексте информационных технологий, когда говорят «база знаний» понимают систему управления базами знаний – конкретный программный продукт, в котором в структурированном виде собраны знания компании по конкретным предметным областям.
Для чего нужны базы знаний
В самом общем представлении, базы знаний решают такие задачи:
- Собрать в одном месте все знания, накопленные в компании
- Предоставить возможность быстрого поиска
- Возможность поделиться знаниями внутри компании (или за пределами, если необходимо)
Для чего на самом деле нужно собирать, искать и делиться? Возьмём для примера службу технической поддержки, организованную по рекомендациям ITIL. Первая линия поддержки представлена специалистами минимальной квалификации, имеющих мало знаний по предметным областям поддержки. Основной навык таких специалистов – это способность быстро искать нужную информацию и работать с конкретным инструментом организации поддержки (Service Desk системой). От того как быстро смогут специалисты первой линии искать информацию во внутренней базе знаний напрямую зависит скорость закрытия обращений и, как следствие, удовлетворённость пользователей.
Service Desk это всего лишь один из примеров. Onboarding и адаптация новых сотрудников, обучение, работа в рамках проекта, выпуск новых релизов, принятие ежедневных решений – всё это требует возможности быстрого доступа к базам знаний и возможности найти и поделиться конкретной записью или частью информации.
С чего начать работу с базами знаний
Мне нравится подход, который предлагает ITIL4 с точки зрения внедрения чего-либо нового. Один из руководящих принципов ITIL4 – «Start where You are». Если транслировать этот принцип на базы знаний, то получится следующее:
- Посмотрите на существующие базы знаний максимально объективно. В том или ином виде, базы знаний у вас уже есть (даже если вы думаете, что нету). Это могут быть просто папки на общих дисках, записи в различных информационных системах, различные системы помощи и подсказки, инструкции и всё что накоплено за период деятельности.
- Определите, какие практики наиболее успешны. Чем более активно пользуются? Общими документами в облаке? Общим диском? Корпоративным порталом?
- Оцените риски всех имеющихся решений. Какие риски вы будете нести, если будете пользоваться общим диском? А файлами в облаке? Или может уже есть wiki система, но в ней нет управления правами доступа?
- Примите для себя, что иногда ничего из того, что уже есть, не может быть использовано. Это редкая ситуация, но нужно быть готовыми выстроить всё с нуля.
Важный аспект, который я всегда подчёркиваю в своих публикациях: процессы прежде инструментов. Прежде чем заниматься внедрением конкретного инструмента (wiki движка, специализированной СУБЗ, писать свою систему) подумайте о правилах и инструкциях. Правила дорожного движения одинаковы для всех. Не важно, едете ли вы на мотоцикле, внедорожнике или многотонном самосвале. Инструменты разные – правила одни.
Какую систему выбрать?
Да на самом деле не важно. Большинство современных систем управления базами знаний предоставляют примерно одинаковый набор опций, всё зависит от вашей возможности размещения. Я рекомендую вообще для любых новых закупок\установок сперва провести MoSCoW анализ, и на основании уже чёткой методики подходить к выбору инструмента.
Оценка базы знаний
К слову об этом. Я видел четыре организации, которые пытались перенести свои знания в централизованные системы, и забросили на полпути. Понять, пользуются ли вашим инструментом, и насколько качественный контент у вас там содержится, помогут регулярные измерения и оценка. Оценку можно проводить как по результатам аудита, так и на основании контроля метрик. С аудитом всё понятно – взяли экспертную группу, провели анализ, дали результаты. Или опрос по пользователям, на худой конец. С метриками чуть сложнее. Попробую накидать примеры, которые видел в практике и которые реально работали.
- Использование системы:
— по результатам закрытия обращения \ инцидента – в системе ставится признак «закрыто с использованием базы знаний»
— по результатам проведения обучения, с отметкой материалов, использованных в обучении
— по результатам мониторинга (подсчёта) количества обращений к системе
- Качество и объём контента:
— Процент роста количества материалов
— Уровень пользовательской удовлетворённости (лайки \ дизлайки под материалами)
— Уровень пользовательской удовлетворённости результатами поиска (лайки \ дизлайки выставленные страницам поиска)
— Доля актуализированных записей. Показатель позволяет контролировать работу по актуализации материалов в связи с изменениями в предметной области
Добавить комментарий