Портал №1 по управлению цифровыми
и информационными технологиями

Вопрос из зала: построение базы знаний

Опубликовано 25 сентября 2014
Рубрики: Вопрос из зала, Управление знаниями
Комментарии

Knowledge_Base_IconНаш читатель, Николай Дмуха, просит поделиться опытом построения базы знаний.

Добрый день.
Хотим внедрить в отдел ТП функционал для траблшутинга какой-либо проблемы наподобие помощника Windows.

У нас есть много полезных инструкций, но все они созданы как темы на форуме. Часто бывает трудно быстро (да и не быстро) найти нужную. Вот встал вопрос о том как привести все это в порядок, сделать некую базу знаний. Вариантов видим несколько: Wiki, своя веб-форма, FAQ и пр. Но хочется все эти полезности прикрутить к работе инженеров ТП, дабы облегчить работу как новичкам, так и старожилам.
Идея такая: есть форма. Слева видим древовидную структуру по разделам:

  • Не работает интернет:
  • Не работает ТВ:
  • Не открывается сайт:
  • Не работает какое-либо ПО:

Поступает задача. Инженер выбирает раздел в соответствии с описанием проблемы. Ну и далее поехали: если "не работает сайт", то при нажатии раскрывается этот раздел. А там несколько пунктов:

  • Проверить настройки DNS
  • Выполнить трассировку
  • Выполнить telnet

…

Ну и соответственно в правой части формы открывается инструкция для выполнения проверки.

В Wiki реализовать такое не получится, сделать свою собственную форму – легко. Но может быть все-таки есть какое-то интересное решение для данной задачи? Может быть у вас есть опыт подобного решения?

Зачем это нужно? Мы можем вести логирование действий инженера и смотреть ход диагностики и решения задачи, чтобы позднее анализировать поступаемые задачи, эффективность инструкций, квалификацию инженеров и т.д.
Пытался что-то подобное поискать в гугле. Но, честно говоря, не знаю даже как задать вопрос. Вроде бы это и KMS, но в то же время чуть отличается.

Буду благодарен за советы, комментарии, подсказки!

 

ОБУЧЕНИЕ
Учебные курсы и сертификация на русском языке
специалистов по ИТ-менеджменту

Также по теме:

Комментариев: 16

  • Игорь Москалев

    Здравствуйте!

    Правильно я понял, что задача стоит так: мониторить передвижения сотрудника по базе знаний с привязкой к инценденту в системе управления инцендентами?

    Очень интересная задача! Положил в копилку идей своего будущего проекта 🙂

    Реализовать это получится, как мне кажется, только написав специальный плагин к чему-нибудь. Да хоть к вики. Первоначальный переход в базу знаний будет осуществляться по ссылке с маркером-ссылкой на инцендент. Ну а далее дело техники. Думаю разработка такого плагина, да хоть к вики, будет стоить совсем недорого.

    Хочу поделиться общими мыслями о состоянии дел с базами знаниями:

    1. Вики – это прошлый век. Особенно в условиях использования вики среди не айтишников. да и айтишники айтишникам рознь. в общем организовать процесс наполнения БЗ с вики – последнее дело. Самый простой пример: вставить картинку проще все-таки копипастом, а не десятком кликов с загрузкой файла на сервер

    2. Воспро поддержания актуальности знаний – проблема не менее актуальная, и актуальная в большей степени для невики решений.

    В данный момент я строю базу знаний на основе OneNote. Благо ныне это бесплатное решение (если не заморачиваться с правами доступа, шейрпойнтом и тп)

    Из облачных решений мне бы приглянулся Evernote для бизнеса.

    Но все эти инструменты не годятся в случае работы с большими объемами динамично изменяющихся материалов, отсутствует семантика и множество основных вещей для управления знаниями.

    и я не знаю что делать. видимо буду делать что-то свое.

    если кто может ткнуть пальцем в какое-то готовое взрослое решение, давно выросшее по удобство и функционалу за пределы вики, ткните, пожалуйста 🙂

    • Владимир Капустин

      Evernote для бизнеса не видел, а лично для себя – сделал из него Энотеку в смартфоне. Удобно 🙂

      • Игорь Москалев

        Я в эвернот построил свой ГТД. Управление личными рабочими задачами и личной базой знаний строю через него.

  • Олег Скрынник

    хочется все эти полезности прикрутить к работе инженеров ТП, дабы облегчить работу как новичкам, так и старожилам.

    На мой взгляд это отличная идея, её обязательно нужно реализовать. Кто-то подходит к такой задаче через написание коротких инструкций или чек-листов, кто-то использует возможности имеющейся системы автоматизации ITSM.

    Я бы обратил внимание не на технический вопрос, его наверняка можно решить, а на традиционно "больную" тему – человеческий фактор. Что будет побуждать ваших инженеров ТП создавать такие подсказки для других?

    Вы, конечно, всем им расскажете, что это очень важно и полезно, и приведёте примеры. И даже можете издать распоряжение или приказ. И показать личный пример. Таких действий хватит на месяц-другой, но ведь очень хочется, чтобы ваша база знаний была постоянно используемым рабочим инструментом, а значит она должна регулярно пополняться новым контентом.

    • Владимир Капустин

      Можно поиграться с геймификацией – напридумывать статусов и званий, которые будут получать сотрудники за баллы, которых будет начисляться тем больше, чем популярнее окажется статья, которую они напишут. 

  • Альберт

    Думаю, что лучше всего отталкиваться интерфейсов системы Service Desk если такая существует. Тогда можно будет делать привязку базы знаний к конкретным инцидентам/проблемам и вести какую-то статистику.

  • Nargiza Suleymanova

    Надеюсь, я правильно поняла автора и речь действительно идет о базе данных типовых решений инцидентов. По этому поводу следующие мысли:

    1. Неплохо было бы привязать к каждой услуге (описанной в каталоге услуг) список типовых инцидентов. Это упростит и регистрацию инцидентов, и их приоритезацию, и, конечно, возможность быстрого поиска подходящего решения.

    2. Практически в любой современной системе SD есть возможность управления знаниями, соответственно, сделать привязку готовых решений к типовым инцидентам будет несложно.

    3. Про актуальность и удобство типовых решений: тут либо назначать конкретного ответственного за состояние БЗ, либо самих сотрудников поощрять за заполнение и поддержание актуальности решений. Тут и KPI, и считать сколько раз применялось то или иное решение, или прикрутить кнопку о полезности/неполезности решения и статистику снимать соответствующую.

    Примерно так 🙂

    • Дмитрий Исайченко

      Тут и KPI, и считать сколько раз применялось то или иное решение, или прикрутить кнопку о полезности/неполезности решения и статистику снимать соответствующую.

      У нас в компании писать в БЗ – круто. Значит, ты смог подняться над уровнем текущей загрузки и учишься, рефлексируешь – растёшь. Все знают, что те, кто пишет в БЗ – большие молодцы. При этом никаких стимулов и KPI мы не используем. База растёт медленно (медленнее, чем мне бы хотелось), зато содержит качественную информацию.

      • Геннадий

        Помнится примерно так же по идее считалось в одной компании. Даже в аттестациях можно было отмечать, что наполняешь базу своими знаниями, чтобы похвалили. И было удобно – если что забыл – всегда можно вспомнить, или найти ответ описанный коллегой прочитать и знания получить.

        Только правда жизни оказывалась в итоге "ты смог подняться над уровнем текущей загрузки" – "специалисту нечем заняться, надо быть построже с его нагрузкой". 😉

        Вроде и молодец что пишешь, но делали это 2-3 человека из 40. Как, в принципе, и искали там ответы на свои вопросы 🙂 Да это было в виде форума, но довольно структурированного и удобного для использования. Проблема скорее была в человеческом факторе и нежелании делиться "сокровенными" знаниями.

        Как такую проблему решить? Техническое решение при решении этого вопроса уже мелочи, может оказаться даже вики или форумы применимы.

        • Дмитрий Исайченко

          Как такую проблему решить?

          Ответ одновременно и простой, и непростой. Работать с людьми, прививать им другую культуру работы, а ещё лучше – набирать тех, кому такая культура изначально ближе. В большой компании это очень трудоемкий путь, но: а) у линейного руководителя подчиненных поменьше, а именно линейные руководители имеют наиболее прямое влияние на исполнителей и б) другие пути мне неизвестны – до KM надо дорасти, в него не загнать.

  • Дмитрий Исайченко

    Мы можем вести логирование действий инженера и смотреть ход диагностики и решения задачи, чтобы позднее анализировать поступаемые задачи, эффективность инструкций, квалификацию инженеров и т.д.

    Очень любопытно, кто, когда и зачем (на основании каких стимулов) будет заниматься таким анализом. Обычно на подобные когнитивные исследования категорически не хватает времени, а у линейных менеджеров – еще и желания. Причем данные для анализа будут очень слабо структурированными, поэтому результативность, скорее всего, может достигаться только регулярностью проведения. В общем, из всего описанного сценария, именно эта часть вызывает у меня наибольшие сомнения с точки зрения практической реализации. Она полностью зависит от личности конкретного руководителя, и поэтому наименее надёжна и управляема.

    Зато если это всё случится, может получиться действительно круто.

    • Владимир Капустин

      Мы и так этим занимаемся. Только данные поступают в ещё менее удобном виде – из прослушанной выборки звонков. Но благодаря этой информации можно чётко понимать, что стоит улучшать в первую очередь.

  • Николай

    Добрый день. Всем спасибо за комментарии.

    Я тоже считаю, что Wiki не очень подходит, т.к. работает в целом достаточно медленно. А у нас время очень важно. Я пробьовал этот вариант. Создал пару страниц, но не понравилось. Попрбовал Atlassian – чуть быстрее, но также остался не доволен. Да и мало ли что случится с ресурсом, в самый нужный момент будет недоступен:)

    Наполнять базу  скорее всего будут инженеры ТП. Они уже пишут статьи, за что получают бонусы.

    Мы регулярно прослушиваем записи звонков абонентов  в ТП, оцениваем их компетентность, вежливость. Мне кажется, что если мы сможем смотреть еще и что именно делал инженер для решения задачи, то мы сможем обучать ребят: вот здесь нужно сделать то, здесь – другое.

    Конечно, всегда есть вариант написать некую форму самим. Но она потом может вырасти в нечто большее, что сразу мы не предусмотрим. Поэтому и хочется найти что-то, как сказал Игорь Москалев, "взрослое"!

  • Андрей

    Традиционно по-занудствую. Вопрос о внедрении функционала-инструмента. Хоть и банально, но напомню, что задача инструмента – обеспечивать работу процесса. Следовательно, требования к инструменту(что в нем можно делать) формируются не из фантазий, а на основе анализа процесса. В священной библиотеке есть такой процесс –Knowledge management (KM) is the process of capturing, developing, sharing, and effectively using organisational knowledge. Если есть желание максимально соответствовать рекомендациям, то инструмент должен поддерживать все упомянутые области процесса. Capturing – существует два источника – внешние базы знаний (от вендоров, из различных форумов и т.д.) и результаты собственного хождения по граблям. Для собственных достижений в некоторых ServiceDesk(SD) есть кнопка при закрытии инцидента – delegate fo KB. Developing – этот шаг посвящен приведению в порядок захваченных знаний. Для внешних источников это приведение к единый формат, для собственных – привлечение экспертов к оценке предоложенных решений и выработке оптимальных. Sharing – в вопросе присутствовал пример реализации со структурами в форме. Это хорошо, но мало. Очень полезна функция работы с эвфемизмами. Термины, которыми оперируют пользователи при описании своих проблем очень часто не укладываются в понятные вам определения: принтер – печаталка, хрень с порошком и т.д.  Effectively using organisational knowledge – тут да, различные KPI, причем не только для тех кто пользуется, но и для тех, кто наполняет.

    НО, самое главное – это ПРОЦЕСС. У него должны быть исполнители. Поэтому должны быть люди, для которых наполение, редактирование и прочие действия с KB – работа, а не факультативное занятие.

     

  • Семен Ешин

    Николай, как я понял, речь идет фактически о дереве принятия решений (descision tree).

    В Сети довольно много библиотек по обработки таких деревьев. Также есть различные приложения, но они носят скорее академический характер, либо являются компонентами систем анализа данных. Поэтому искать следует как раз информацию, относящуюся к этим деревьям.

    Также, на мой взгляд, нет смысла вручную проводить анализ цепочки диагностирующих действий. Если такую информацию хранить в системе (например, в привязке к обращению), вы сможете автоматически провести по этим данным обучение дерева, т.е. получить оценки вероятностей для каждого ветвеления. В данному случае речь уже идет о вероятностном дереве решений.

    В дальнейшем по мере накопления информации эти оценки будут уточняться и инженеру система всегда сможет предложить, по какой ветке диагностирования следует пойти (т.е. какая ветка с наибольшей вероятностью приведет к цели). Преимущество такого подхода ясно: инженер не будет совершать дополнительных диагностических действий, а в большинстве случаев будет двигаться кратчайшим путем. 

    Методическую и алгоритмическую часть вам следует искать в соотв. литературе по теории принятия решения/машинному обучению, а бибилотек, как я уже сказал, достаточно в сети, в т.ч. открытых.

  • Николай

    Семен, спасибо большое за ваш комментарий. Да, термин "дерево принятия решений" очень точно описывает нашу хотелку:) Попробую поработать в этом направлении!

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.