На определенном этапе развития вашей ИТ-структуры может возникнуть вопрос об организации Базы знаний (далее — БЗ) как для ИТ-сотрудников, так и для бизнес-пользователей.
Реализация этой идеи может иметь как положительный эффект, так и вызвать серьезную головную боль у всех участников проекта: от бизнеса, финансирующего его, до менеджера проекта, координирующего реализацию.
В этой заметке я постараюсь раскрыть несколько моментов, с которыми мы столкнулись, а также дать некоторые рекомендации.
Процесс создания базы знаний можно рассматривать с точки зрения принципиально разных структур в организации: для ИТ-пользователей, для бизнеса — и того, и другого одновременно.
КБ для ИТ и бизнеса.
Если вы решили, что КБ актуально для всей организации, то стоит заручиться моральной и финансовой поддержкой представителей бизнеса и технических директоров.
Это поможет вашему проекту получить должную гарантию и в будущем позволит избежать неприятных инцидентов, связанных с непониманием целей или, на более низком уровне, недовольством качеством присланных статей.
• Старайтесь ответственно подходить к элементам интерфейса и выбору среды разработки.
Инструменты поиска важны.
Если этот элемент будет работать плохо, то смысла в такой базе данных будет мало: база данных, чтобы в ней можно было что-то найти! Не стоит недооценивать этот момент. Поскольку в вашей организации есть тысячи и тысячи статей, проблема будет становиться все более ощутимой; • Используйте четкую категоризацию.
Те категории, которые будут понятны ИТ-специалисту, могут совершенно ничего не значить для бизнес-пользователя.
Постарайтесь объединить категории, отражающие названия бизнес-процессов, и понятные нам подкатегории; • Выбор системы.
Пункт не менее важен, так как пользователю будет удобнее работать с БЗ из той среды, в которой у него будут возникать вопросы.
Возможно, удачным решением станет система обслуживания запросов пользователей.
Подумайте о способах объединения управления инцидентами и управления знаниями; • Не спешите открывать свою базу пользователей.
Даже самое лучшее и интересное решение может надолго оттолкнуть пользователей, если оно состоит из 10 статей.
Подготовьтесь заранее.
Для начала напишите статьи по тем вопросам, которые вы считаете наиболее актуальными; • Отделите базу знаний ИТ от базы знаний пользователя.
И не для того, чтобы скрыть от них то, чего они не должны видеть.
Пользовательским статьям следует уделять больше внимания.
Сюда входит стиль изложения и отказ от использования IT-сленга и аббревиатур.
Убедитесь, что все, что вы публикуете, может быть технически использовано пользователем; • Используйте систему контроля и модерации статей перед публикацией.
Одна голова это хорошо, а две лучше.
Это позволит избавиться от некомпетентных знаний и досадных ошибок; • Заявки на статьи.
Реализовать возможность добавления запросов на статьи определенного содержания.
Пользователи лучше информированы о том, что им нужно, а что нет; • Напишите документацию о том, как использовать инструмент, и постарайтесь сначала обеспечить интенсивную поддержку.
Практика показывает, что пользователи в целом положительно относятся к идее создания базы ИТ-знаний, однако не следует делать из нее замену технической поддержки, по крайней мере, на первых порах об этом даже думать не следует. Презентуйте инструмент как дополнительный канал решения проблем и рекламируйте его.
Например, решив проблему устно или на бумаге, имеет смысл задокументировать ее в КБ и отправить ссылку пользователю.
КБ для ИТ.
Использование базы знаний в ИТ-структуре может быть полезным во многих случаях.
• Обучение новых сотрудников; • Передача текущих знаний тем, кто не является глубоким экспертом в этой области; • Обмен знаниями с ИТ-отделами.
На этом этапе у вас могут возникнуть проблемы совершенно другого типа, чем те, с которыми потенциально сталкивается бизнес.
• «Зачем мне КБ, ведь я и так все знаю и могу легко объяснить пользователю».
Это очень распространенный вопрос, который поступает к нам от пользователей и авторов базы знаний.
Написание статей отнимает время, которое сотрудник хочет потратить на что-то другое, не менее полезное, по его мнению.
Обязать человека что-то сделать можно, но вряд ли это даст хороший эффект в виде качественных статей.
Постарайтесь донести до людей не столько то, что инструмент кому-то поможет, сколько то, что он будет полезен лично ему, а это, в первую очередь, экономит время: на общении с пользователями и с менее компетентными коллегами.
Например, имея сейчас пять минут и потратив их на написание статьи, мы сохраним ее, когда у нас не будет этих пяти минут на объяснение проблемы/функционала; • Плохая техническая реализация.
Важный момент, который легко может испортить идею.
Постарайтесь сделать инструмент удобным.
Если у него есть встроенный текстовый редактор, заставьте его работать безупречно.
Если статьи писать неудобно, то писать не будут; • Мониторинг.
Старайтесь следить не только за тем, сколько статей написано и кто лично это делает, но и проверять их актуальность.
Добавьте функциональность счетчиков просмотров и отзывов.
Разрешить пользователям оставлять комментарии к статьям.
Создайте несколько отчетов.
Старайтесь следить за дубликатами.
Вероятность их появления также будет возрастать по мере роста базы.
В общем, все, что связано с КБ, не следует внедрять в спешке.
Можно потратить много времени и денег на техническую реализацию и не добиться никакого эффекта из-за мелких недочетов и досадных ошибок.
А цель таких систем – уменьшить количество контактов с несущими конструкциями.
Конечно, количество подводных камней существенно больше, чем я указал в статье, но описанные — самые важные.
Готов выслушать ваши комментарии и буду рад, если вы поделитесь своим опытом.
Теги: #управление знаниями #Образовательный процесс в ИТ
-
Аниме-Шоу В Интернете
19 Oct, 24 -
Картриджи Epson Для Чудесной Печати
19 Oct, 24 -
Индийские Программисты Покидают Америку
19 Oct, 24 -
Есть Ли Плагин/Виджет Для Ссылок На Сервисы?
19 Oct, 24 -
Сборка Компьютера В Сети
19 Oct, 24 -
Сканирование Пленки Зеркальной Камерой.
19 Oct, 24
