8,1
рейтинг
19 апреля 2012 в 14:30

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

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

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

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



Конечно же, анализировать каждую ветвь этого пусть и небольшого дерева не имеет смысла, поэтому направление для детализации было сильно сужено с учетом жизненных реалий и результатов исследования. Полноты ради не могу не упомянуть про два примера создания базы знаний (БЗ) именно в ИТ области. Первый, это БЗ крупной консалтинговой компании 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
карма
19,5
рейтинг 8,1
Аналитик
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Управление

Комментарии (18)

  • +1
    Проблема есть. И она очевидна, по крайней мере для сотрудников средних и крупных компаний. Самому осточертело бегать между отделами и руководителями в поисках нужной информации для создания общей картины. (о клиентах, поставщиках, да и вообще о любом проекте). Проблема наверно в том, что нет подходящего ПО, которое бы создавало общую площадку для сбора и считывания информации, что-то вроде википедии. А Руководители просто не хотят париться, создавать что-то с нуля.

    Ждем ПО от вас! :)
    • 0
      Кто знает, может такое ПО действительно когда-нибудь появится;)

      подходящего ПО, которое бы создавало общую площадку для сбора и считывания информации, что-то вроде википедии

      Ну «вроде википедии» запросто можно найти софт. И даже лучше, те же упомянутые семантические вики с корпоративным уклоном. Проблемы-то в другом. Например, нет такого community-driven настроения, как у активных пользователей википедии.
      • 0
        Я согласен с вами, что основная масса не будет себя утруждать, нет мотивации. Тем не менее, думаю найдутся люди, которые с удовольствием поделяться своими знаниями, опытом. С другой стороны можно создать стимул корпоротивному обществу. Или в конце концов нанять человека на зарплате, пущай бегает и собирает инфу. Все равно это окупиться.
        • 0
          Согласен, если обеспечить возможность и предоставить её, какой-то процент сотрудников все равно будет этим заниматься.

          А человеку на зарплате скорее не собирать, а структурировать всё нужно. я плохо представляю, куда нужно бежать, чтобы вытянуть полезное, возникшее в ходе решения какой-либо задачи знание, оставшееся в головах и в джаббере при переписке менеджера и разработчика, например;)
    • 0
      Прошу пояснить чем не подходит для накопления знаний локальный Web сайт с wiki движком.
      Если персонал не хочет наполнять базу знаний то это уже не технический вопрос

      • 0
        Подходит, почему нет. Wiki в основном и используются сейчас для этих целей.
        Вопрос в том, что они не оптимальны для работы со знаниями и слишком оторваны от рабочего процесса. Кое-какие улучшения в эту сторону ведутся, и о них, я как раз упомянул в этой статье.
  • +1
    Как представитель IBS могу сказать: действительно, данные сильно устаревшие, да и, честно говоря, ровно так, как в той презентации, это никогда и не работало. В презентации описана целевая архитектура, на ее основе был разработан прототип, но, насколько я помню (очень давнее дело), дальше прототипа дело не пошло.

    • 0
      Я кажется понял основную идею Никиты. Тут собрана картинка как вообще обстоит дело с knowledge mngmt.

      На мой взгляд в большой организации сложнее сделать целостную систему работы со знаниями достаточно сложно. И вообще есть мнение что малых команд будет все больше и размеры команд будет уменьшаться. И менеджмент проектов в сегодняшнем понимании превратиться в проектные сети. И это то как мы в команде Rizzoma видим будущее.
      • 0
        Да, действительно. Серия статей получилась примерно об этом. Правда непреднамеренно. А здесь еще затронул по верхам системы, которые удалось хоть немного пощупать.

        И вообще есть мнение что малых команд будет все больше и размеры команд будет уменьшаться.

        Команды да, но организации большие все равно останутся. И может быть научаться все такие эффективно управлять всем этим хозяйством
    • 0
      Жаль, что все на прототипе остановилось. Результаты были бы интересны.

      Там в презентации есть расчет экономических показателей, получается он с потолка был взят? я-то думал, что это уже реальные собранные данные…
      • 0
        Потому и остановились, что по итогам тестирования на прототипе, что называется «не пошло». Экон.эффект, я полагаю, написан предполагаемый\потенциальный, рассчитанный на основе бенчмаркинга, по какому-нибудь западному опыту.

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

        Сейчас система обмена знаниями существует, но несколько в другом виде, — в подразделениях и проектных командах, а не в масштабах всей компании.
        • 0
          Ответил не в ту ветку. смотрите ниже
  • 0
    документирование экспертизы

    а что вы имеете в виду под экспертизой?

    несколько в другом виде, — в подразделениях и проектных командах

    А можно подробнее? Поделитесь опытом реализации. Что за другой вид. Надеюсь, эта информация не относится к закрытой корпоративной. Многим интересен был бы ваш опыт.
    • 0
      Экспертиза в смысле экспертное знание (это наш жаргон, наверное, но смысл понятен).

      Описать, как это у нас сейчас устроено, — хорошая тема, я готов позадавать вопросы людям в командах, чтобы было конкретно, а не в общем.
      • 0
        Отлично, я думаю это интересно. Сформулирую вопросы, посоветуюсь еще с кем-нибудь и напишу тогда вам дополнительно.
  • 0
    NikMelnikov, когда используете в статье чужие материалы, то хорошо бы на них ссылаться. А то перерисовать картинку с классификацией ПО для СУЗ время нашлось, а сослаться на первоисточник — нет :(
    см. www.bigc.ru/publications/bigspb/km/itkm/
    • 0
      А её и назвал «наиболее известной классификацией». Перерисовывал для диплома, там ссылка была. Здесь, виноват, не проставил.
    • 0
      исправлено;)

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.