Управление знаниями, создание базы знаний. А что на практике?

в 10:30, , рубрики: Без рубрики

Продолжая тему двух предыдущих постов (первый и второй), в которых проводилось исследование на тему управления знаниями и были рассказаны основные результаты, хотелось бы углубиться в практическую составляющую данной проблемы. Вопросов для обсуждения здесь предостаточно, но основной — существуют ли инструменты, позволяющие удовлетворить все потребности бизнеса в части управления знаниями? Попробуем ответить на этот вопрос со своей «колокольни».

Классификация систем управления знаниями

Рынок программного обеспечения по управлению знаниями крайне неоднозначен. Это связано с тем, что направление относительно молодое, а само определение понятия «управление знаниями» трактуется разными авторами по-разному, о чем мы уже говорили в первом топике на эту тему. Наиболее известная классификация приведена на картинке ниже. Отнесение такого широкого класса ПО к системам управления знаниями (СУЗ) объясняется тем, что в СУЗ знаниями называют все виды информации, включая неструктурированный контент (письма, эскизы, фото), данные (в базах данных и хранилищах данных), и знания (как закономерности предметной области, позволяющие специалистам решать свои задачи).

Управление знаниями, создание базы знаний. А что на практике?

Конечно же, анализировать каждую ветвь этого пусть и небольшого дерева не имеет смысла, поэтому направление для детализации было сильно сужено с учетом жизненных реалий и результатов исследования. Полноты ради не могу не упомянуть про два примера создания базы знаний (БЗ) именно в ИТ области. Первый, это БЗ крупной консалтинговой компании IBS. Информация достаточно старая, с тех пор наверняка что-то поменялось. Упомянуть хотелось бы лишь некоторые основные моменты, остальное вы сами можете посмотреть в презентации.

Основным понятием в БЗ IBS является документ. Вся работа с БЗ от пополнения до использования вертится именно вокруг документов. В качестве ПП для такого, казалось бы, простого подхода используются сразу три разнородных и дорогостоящих решения. Это Documentim, SAP R/3 и Lotus. Согласитесь, троица впечатляющая. Хочется верить, что на тот момент особых альтернатив не было, а к сегодняшнему дню уже что-нибудь поменялось. Представителей компании случайно нет на хабре?

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

А что нам нужно

В предыдущем параграфе были показаны российские работающие примеры. Ниже попытка выбрать направление и критерии, на которые я обращал внимание, когда обрисовывал СУЗ:

  1. Использование семантических технологий. При работе со знаниями, семантику игнорировать не стоит. Один из основополагающих моментов.
  2. Ориентация на малый и средний бизнес. Понятно, что с помощью Documentum можно закрыть массу вопросов, связанных с ИТ-инфраструктурой, а SharePoint по мнению Microsoft умеет вообще всё, но нужно что-то более приземленное.
  3. Поддержка совместной работы и высокая степень интероперабельности. Если с коллаборативностью у большинства корпоративных информационных систем дела более-менее, то интеропребельность (не люблю заимствованные термины) везде разная. Очевидно, что БЗ не должна быть закрытой и обособленной ИС.
  4. Мелочи-полезности, которые проявились из опроса, а именно: увязка БЗ с workflow и использование визуализации (в частности, mind mapping).

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

Возник главный вопрос, а где же использование семантических технологий, ведь оно стоит на первом месте? Оказалось, что среди вики-систем уже давно выделяют семантические вики, и именно этому контексту будет посвящен остаток этой статьи. Был очень удивлен, что на хабре упоминаний, посвященных этой теме совсем немного. Если вкратце, то основная отличительная особенность по сравнению с традиционными вики — возможность указывать тип ссылок между статьями, типы данных внутри статей, а также информацию о страницах. Это предложение из одноименной статьи в википедии, за полным описанием туда.

Другими словами, семантические вики позволяют организовывать и структурировать информацию более эффективно. Многие семантические вики поддерживают rdf и owl, что позволяет добиться более жесткой формализации, а вместе с ризонерами (reasoner) и поддержки логического вывода. С первого взгляда кажется, что всё это — лишнее усложнение, которое станет еще одним препятствием для конечного пользователя. Однако на практике работу с типизированными данными можно организовать с помощью семантических форм, и для пользователя это будет выглядеть как очередная анкета, с которой просто оперировать.

Семантические вики. Увы их тоже много

Самым показательным примером семантических вики является надстройка над движком MediaWiki, называющаяся лаконично и понятно Semantic MediaWiki. Распространяется под хорошей лицензией GNU GPL v.2 Идеально для тех, кто уже использует media wiki, хочет открытости, простоты и прочих возможностей подобной политики лицензирования. Расширений у нее очень много, полезных и не очень. В общем взглянуть стоит.

Среди всех прочих семантических вики я остановлюсь только на двух, с которыми имел возможность хоть немного, но поработать. Обе они распространяются под коммерческими лицензиями, но имеют также и community версию с несколько ограниченным функционалом. Почему на них? потому что они имеют бОльшую корпоративную направленность.

Первая — это semantic media wiki plus. Базируется на том же самом расширении semantic media wiki и дополнена богатым и крайне важным функционалом, упрощающим и одновременно расширяющим возможности семантических вики. Плюс всё необходимое сразу собрано в один пакет, что было важно для меня, когда я присматривался и выбирал конкретную систему. Рекламировать больше не буду, за меня гораздо эффективнее это сделает сайт продукта. Что понравилось:

Прекрасные возможности по интеграции, в т.ч. числе и уже разработанные. Например, с продуктами Microsoft Office (Word, Project), электронной почтой, тем же SharePoint. Сюда же — возможность написания коннекторов для своих приложений.
В качестве примера использования можно установить уже созданные онтологии project и risk management. Наглядно, понятно, еще бы кто-нибудь попробовал на деле. В случае чего структуру всегда можно изменить под себя, это на самом деле несложно. Так же понравилось, что в вики с описанием самой системы были выделены типичные роли, которые показательны для такого класса систем: ontologist, gardener, end user, developer, administrator. Пожалуй, двух абзацев достаточно, подробнее можно и на сайте посмотреть.

Второй продукт, с которым довелось совсем немного познакомиться, подойдет для тех, кто по тем или иным причинам предпочитает java-технологии. Называется Information Workbench (IWB). Продукт ровно как и компания его разработавшая относительно молодые. Не буду писать про возможности и прочие полезности, предлагаю взглянуть на архитектуру и отправиться на сайт разработчика за всей информацией. Отмечу лишь то, что реализация пока сыровата, но все делается грамотно и профессионально. и научно;) Как мне сказала представитель компании: «оба наших директора Ph.D.»

Визуализация — Mind map, WorkFlow и Confulence

В данной части вкратце остановлюсь на этих трех разнородных словах.

Не таю, что визуализации с самого начала уделял много внимания. Даже вопрос отдельный завел в опроснике. Причина — информацию мы воспринимаем лучше в визуальной форме (перечитывал свой текст, еще раз убедился в этом). Для работы со знаниями самая лучшая визуализация — использование mind map (тут кстати статья неплохая была про данную методологию).
Так вот. Во всех вики с этим дела обстоят так себе. У freemind только есть возможность вставки (embed), уже хорошо. Может, конечно, где-нибудь что-нибудь опустил.

Впрочем есть и альтернативные подходы. Например в IWB есть представление онтологии, лежащей в основе вики в виде графа. Очень удобно. Это можно эффективно использовать. Если семантическая вики поддерживает SPARQL endpoint можно попробовать прикрутить RelFinder, который будет сторонним визуализатором БЗ. Чтобы понять механизм действия можно посмотреть готовый пример с Энштейном и Гёделем. Или самостоятельно выяснить, что общего, например, у Москвы и Пушкина.

WorkFlow. Знания в отрыве от практической деятельности не нужны. Какой в них смысл, если их не применять. Повседневная деятельность может быть отражена в WorkFlow. Что здесь?

А здесь тоже не очень. С одной стороны тот же SMW+ заявляет, что smw+ “tool that well suited for organizations or teams dealing with heterogeneous and informal workflows”. Но нормального прагматичного решения увязки workflow и базы знаний нет. Вот хороший комментарий на этот счет:

Some first ideas (I deliberately don't make a real distinction between a workflow and a BP here)
— using the wiki to create/improve workflows/processes => The ideal is if you can generate a process from the (final) wiki info
— using the wiki do document workflows/processes
— using the wiki to support running workflows/processes (info on background, how to, share experiences, Q&A ...)
— using the workflow/BPM to steer KM processes => push info, trigger people/apps, collect info,
— using the workflow/BPM to steer wiki publishing => approvals etc

Впрочем у BPM пакета Bizagi process modeler есть выгрузка всех отрисованных блоков построенных моделей в категории и статьи Media Wiki. Можно очень удобно их использовать в связки, облегчая себе работу.

Автор комментария на английском дал мне ссылку, где wiki и workflow работают более тесно — www.adhocworkflows.com Это плагин сторонних разработчиков к Confluence. Не ставил, не пробовал, не тестил. Никак прокомментировать не могу, но поделиться считаю, что нужно. Тем более Confulence и Jira совсем рядом, а последней много кто пользуется. Так же для Confluence есть и семантическая надстройка — www.zagile.com/products/wikidsmart.html Отличная альтернатива для тех кто строит вики не с нуля, а перепроектирует уже наполненную имеющуюся. Тоже не тестил, ничего добавить от себя не могу.

А что еще

Как известно, основная проблема в управлении знании в целом и создании базы знаний в частности — нехватка времени и нежелание наполнять базу знаний. Свободное время зачастую тратится на серфинг Интернета, на общение с коллегами. Мысль вслух: «пусть в следующий раз выполняя схожую задачу, мне придется что-то судорожно вспоминать и заново искать, все равно сейчас базой знаний я не займусь, хоть она и поспособствует более благоприятной работе в далеком будущем». Но от этого никуда не деться, только как-то дополнительно стимулировать сотрудников.

В качестве альтернативы рассмотренных выше вики, есть подход, ставящий во главу угла процесс коммуникации. Отчасти здесь фигурирует знание, что подтверждается наличием одного из процесса трансформации знания по известному японскому специалисту Нонака — социализации, левый верхний квадрант.

Здесь я прежде всего имею в виду проект rizzoma. Когда только начинал заниматься поднятым вопросом, очень понравилась одна из их первых статей. Тогда проект был еще под старым именем. Если вкратце, то rizzoma — это продолжение концепции Google Wave, где всё обсуждение строится волнами или blip-ами. «Rizzoma — collaboration-сервис, включающий в себя wiki-систему, мессенджер и, в скором будущем, таск-трекер.» Сервису еще много чего нужно докручивать, тех же тасков сейчас нет, да и вики в привычном понимании не угадывается, но перспективы развития есть. Мне особенно в нем понравилось отображение структуры волн в mindmap. При грамотной организации получается хорошо воспринимая для постороннего человека структура. Имхо — такой подход лучше всего работать будет в связке с семантическими вики, если привить культуру общения в rizzoma, а структурирование возложить на вики.

Жду ваших комментариев. Может быть кто-нибудь пользовался упомянутыми продуктами. Интересно было бы узнать стороннее мнение.

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

Автор: NikMelnikov

Поделиться

* - обязательные к заполнению поля