На определенном этапе развития вашей IT структуры может встать вопрос об организации Knowledge Base (далее KB) как для IT сотрудников, так и для бизнес пользователей. Реализация данной затеи может иметь как положительный эффект, так и может стать причиной серьезной головной боли для всех участников проекта: от бизнеса, финансирующего его, так и проектного менеджера, координируещего реализацию. В этой заметке я попробую раскрыть несколько моментов, с которыми мы столкнулись, а так же дать несколько рекомендаций.
Процесс создания базы знаний может быть рассмотрен с точки зрения принципиально разных структур в организации: для IT пользователей, для бизнеса, тех и других одновременно.
KB для IT и бизнеса.
Если вы приняли решение, что KB актуально для всей организации, то стоит заручится моральной и финансовой поддержкой у представитей бизнеса и технический директоров. Это поможет вашему проекту получить должную гарантию и в дальнейшем позволит избежать неприятных казусов, связанных с недопониманием целей или же, на более низком уровне, недовольством качества представленных статей.
• Старайтесь ответственно подходить к элементам интерфейса и выбора среды для разработки. Важное значение имеет средства поиска. Если этот элемент будет плохо работать, то смысла в такой базе будет немного: база для того, чтобы в ней можно было что-либо найти! Не стоит недооценивать этот пункт. Когда в вашей организации будут тысячи и тысячи статей, проблема будет ощущаться всё сильнее;
• Используйте понятную категоризацию. Те категории, которые будут понятны ITшнику, могут совершенно ничего не говорить бизнес пользователю. Попробуйте совмещать категории, отражающие названия бизнес процессов и подкатегории, понятные нам;
• Выбор системы. Пункт не менее важен, так как пользователю будет удобнее работать с KB из той среды, в которой у него будут возникать вопросы. Возможно, удачным решением станет система ведения заявок пользователей. Подумайте над средствами совмещения Incident и Knowledge Management’а;
• Не спешите открыть базу для пользователей. Даже самое хорошее и интересное решение может надолго оттолкнуть пользователей от себя, если оно будет состоять из 10 статей. Подготовьтесь заранее. Для начала напишите статьи по тем вопросам, которые считаете наиболее актуальными;
• Разграничьте IT KB от KB для пользователей. И не для того, чтобы скрыть от них то, что им видеть не следует. Статьям пользователем следует уделять больше внимания. Это и стиль изложения, и отказ от использования IT сленга и аббревиатур. Убедитесь, что все то, что вы публикуете может быть технически использовано пользователем;
• Используйте систему контроля и модерации статей перед публикацией. Одна голова – хорошо, а две лучше. Это избавит от некомпетентных знаний и досадных помарок;
• Заявки на статьи. Реализуйте возможность добавлять заявки на статьи определенного содержания. Пользователям лучше знать о том, что им нужно, а что нет;
• Напишите документацию о том, как пользоваться средством и старайтесь оказывать intensive support в первое время.
Практика показывает, что пользователи в целом позитивно относятся к идее создания IT базы знаний, однако, не стоит из нее делать замену техподдержки, по крайней мере на первых порах об этом даже не стоит задумываться. Представляйте средство как дополнительный канал для решения проблем и рекламируйте его. К примеру, решив проблему устно или на бумаге, имеет смысл задокументировать ее в KB и отправить ссылку пользователю.
KB для IT.
Использования KB внутри IT структуры может полезно во многих случаях.
• Обучение новых сотрудников;
• Передача актуальных знаний тем, кто не является глубоким специалистом в области;
• Обмен знаниями со смежными с IT департаментами.
На этой стадии у вас могут возникнут совершенно другого рода проблемы, нежели те, который потенциально возможно у бизнеса.
• «Зачем мне KB раз я и так все знаю и легко объясню пользователю». Это очень распространенный вопрос, который приходил к нам от пользователей и авторов KB. Написание статей занимает время, которое сотрудник хочет потратить для что-либо другое, не менее полезное по его мнению. Обязать человека что-либо делать можно, но вряд ли от этого будет хороший эффект в виде качественных статей. Старайтесь доносить до людей не столько то, что средство поможет кому-то, а то, что оно будет полезно лично ему, а это, прежде всего, экономия времени: на общение с пользователями и с не столь компетентными коллегами. К примеру, имея пять минут сейчас, и потратив их на написание статьи, мы съэкономим его тогда, когда этих пяти минут на разъяснение проблемы/функциональности не будет;
• Неудачная техническая реализация. Важный момент, который может легко загубить идею. Старайтесь сделать средство удобным. Если там встроен текстовый редактор, добейтесь от него безупречной работе. Если писать статьи неудобно, то писать не будут;
• Мониторинг. Старайте следить не только за тем, как много пишется статей и кто лично это делает, но и проверяте их актуальность. Добавьте функциональность view counter’ов и feedback’ов. Дайте возможность пользователем оставлять комментарии к статьям. Создайте несколько репортов. Старайтесь следить за появлением дубликатов. Вероятность их появления с ростом базы так же будет расти.
Вообще, все что касается KB не следует внедрять наспех. Вы можете потратить кучу времени и денег на техническую реализацию и не добиться эффекта из-за мелких недочетов и достадных багов. А Цель подобных систем – сократить колличество комнтакты с поддерживающими структурами. Безусловно, колличество подводных камней существенно больше, чем я указал в статье, но описанные – самые главные.
Готов выслушать ваши комментарии и буду рад, если поделитесь опытом.
Автор: zotchy
