Главная  Статьи  Менеджмент знаний  Основные публикации по менеджменту знаний

Онтологический подход к управлению знаниями при разработке корпоративных систем автоматизации¹

Гаврилова Т. А.
"Новости искуственного интеллекта" №2 с. 24-30, 2003.

Среди множества новейших тенденций, программных систем и продуктов легко растеряться даже специалистам. Нужны ли нам все эти модные (и весьма дорогие) ERP, workflow, CALS, CRM и прочие «навороты», ведь угнаться за гонкой аббревиатур в IT-технологиях нет никакой возможности. Новые термины появляются с частотой в полгода, и с той же скоростью исчезают с горизонта.

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

Первая причина – чисто конъюнктурная. Проще всего разницу пояснить на индустрии модной одежды. Конкуренция велика, производителей десятки тысяч, целевая функция одежды не меняется столетиями – чтобы было удобно и красиво. Для привлечения покупателя нужны новые лозунги, новые лэйблы. И вот уже не брюки из ткани «деним», а джинсы; не пиджак, а кардиган и блейзер, и т.д.

Также как в одежде, целевая функция всех систем автоматизации неизменна, это информационная поддержка бизнеса или производства. Все. Дальнейшее зависит от взгляда – как смотреть на весь этот муравейник – сверху, сбоку, изнутри, по-этажно, по-процессно, по-объектно…

Вторая причина связана как раз с различиями во взглядах, или в целях. Название класса системы обычно указывает на ее целевую функцию и это хорошо надо понимать, чтобы потом не удивляться почему пробуксовывает, например, финансовый модуль в западной системе, ориентированной на работу с клиентами класса СRM (Сustomer Relationship Management). Также невозможно требовать от бухгалтерской системы функциональности, присущей, например, системам работы с поставщиками класса SCM (Supply Chain Manament)

Третий аспект связан с тем принципом, согласно которому производится структурирование информации (Рис.1). Критериев декомпозиции и агрегирования информации – сотни, соответственно вопрос состоит в том, насколько Ваше виденье информационной структуры соответствует виденью проблемы разработчиков приобретаемого Вами softa. Правда, из рекламных описаний систем зачастую совершенно невозможно понять тех принципов и, главное ограничений, которые они в себе несут. Это не злой умысел, это естественный взгляд с одной «колокольни».

И, наконец, четвертая объективная проблема, отсутствие специалистов-аналитиков высокого уровня, способных разобраться в реальной системе управления и информационной инфраструктуре компании, с одной стороны, и хорошо знакомых с особенностями и новинками рынка автоматизированных систем, с другой. Таких специалистов нигде не готовят, а умельцы, любовно выращенные на предприятиях, перегружены тактическим «латанием» дырок, а не стратегическим анализом. По уже понятным причинам этих людей не может быть в IT-фирмах (IT – Information Technologies), сопровождающих и внедряющих конкретный продукт.

Выход из этого тупика придуман не нами – это услуги консультантов и/или подготовка аналитиков на предприятии. Подготовка аналитиков настолько сложная задача, что заслуживает отдельного разговора (см. далее).

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

На практике все происходит в точности наоборот – сначала IT-специалисты выбирают инструмент (под влиянием рекламы, лоббирования, личных предпочтений, интереса, своего понимания автоматизации), а затем убеждают в правильности выбора топ-менеджеров. Эта практика стара как и сама автоматизация, так хорошо известен снобистский лозунг первых автоматизаторов во времена советских АСУ “Сделаем клиенту не то, что он просит, а то, что ему нужно!”

Рис.1. иллюстрирует подход к формированию методологии автоматизации, при котором выбор стратегии структурирования рассматривается как минимум наравне с технологией реализации, и ни в коем случае не следует за ней. В то время как на практике технологическая «телега»почти всегда ставится впереди «лошади» структурирования.

Новая концепция «управление знаниями» (УЗ) или Knowledge Management (КМ) действительно помогает поменять взгляд на автоматизацию корпорации, так как акцент в ней ставится на ценность информации. Новизна концепции УЗ заключается в принципиально новой задаче – копить не разрозненную информацию, а знания, т.е. закономерности и принципы, позволяющие решать реальные производственные и бизнес-задачи. При этом в расчет берутся и те знания, которые «невидимы» – они хранятся в памяти специалистов, а не на материальных носителях.

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

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

Управление знаниями  можно рассматривать и как новое направление в менеджменте и как направление в информатике для поддержки процессов создания, распространения, обработки и использования знаний внутри предприятия (Рис.2).

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

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

Из-за этого разнообразия СУЗ вынуждены интегрировать разнообразные технологии:

• электронная почта и Интернет-ресурсы;
• системы управления базами данных (СУБД) и сами базы данных (БД);
• средства создания хранилищ данных (Data Warehousing);
• системы поддержки групповой работы;
• локальные корпоративные системы автоматизации;
• системы документооборота и worlflow;
• экспертные системы и базы знаний и др.

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

Фактически УЗ – это модный лозунг в менеджменте и его связь с инженерией знаний (knowledge engineering) в настоящее время практически эфемерна. Нечеткость различий в понятиях «информация», «данные» и «знания» льет воду на мельницу спекуляций эту тему. Если трактовать информацию, как общий термин для всех информационных ресурсов предприятия (рис.4), то в реальности современные СУЗ занимаются проблемой организации только части информации, в основном документооборота в компании.

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

Фактически системы, позиционирующие себя как СУЗ – системы управления знаниями (Fulcrum, Documentum i4, Knowledge Station, etc.)[Попов, 2001] реализуют лишь отдельные элементы вышепреведенного списка. Все они работают либо с неструктурированной информацией в форме документов, либо с данными (рис.4) Это ситуация as is (как есть), а хотелось бы включения и знаний.

Программные инструментарии для создания хранилищ данных, которые работают по принципу центрального склада, были одним из первых предвестников СУЗ. Как правило, хранилища содержат многолетние версии обычной БД, физически размещаемые в той же самой базе. Когда все данные содержатся в едином хранилище, изучение и анализ связей между отдельными элементами может быть более плодотворным. В дальнейшем идея хранилища была развита в понятие корпоративной памяти (corporate memory) [Kuhn, Abecker, 1998], которая по аналогии с человеческой памятью позволяет пользоваться предыдущим опытом и избегать повторения ошибок, что является пока достаточно декларативным утверждением.

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

Существует множество различных подходов к определению понятия «онтология» [Gruber, 1993]:

Следует отметить, что понимание термина «онтология» зависит от контекста и целей его использования. Можно выделить несколько аспектов его применения, в частности, в работе [Guarino, et al., 1995] выделяются следующие интерпретации:

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

К сожалению, при разработке новых и использовании существующих онтологий возникает множество трудностей. В работе [Arpirez J.; Gomez-Perez, A.; Lozano, A; Pinto S, 1998] выделяются, в частности, следующие:

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

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

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

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

Для описания онтологий и работы с ними существуют различные языки и системы, однако, наиболее перспективным представляется визуальный подход, позволяющий специалистам непосредственно «рисовать» онтологии, что помогает наглядно сформулировать и объяснить природу и структуру явлений. Визуальные модели, например графы, обладают особенной когнитивной (т.е. познавательной) силой. Любой программный графический пакет от PaintBrush до Visio можно использовать как первичный инструмент описания онтологий.

На рис.5 представлена онтология, нарисованная с использованием графического инструмента CAKE-2 (Computer-Aided Knowledge Engineering) (разработчик Т.Е.Гелеверя), методологические основы которого были описаны в работе [Гаврилова, Воинов, Данцин, 1996].

Онтологический инжиниринг – это процесс проектирования и разработки онтологий. При отсутствии общепринятой методологии и технологии этот процесс не является тривиальной задачей. Он требует от разработчиков профессионального владения технологиями инженерии знаний – от методов извлечения знаний до структурирования и формализации [Гаврилова, Хорошевский, 2000].

Онтологический инжиниринг подразумевает глубокий структурный анализ предметной области. Такую работу для интеллектуальных систем обычно выполняют инженеры по знаниям (knowledge engineers).

Сегодня фактически ни один российский вуз не готовит аналитиков или инженеров по знаниям, владеющих методами инженерии знаний. Наиболее близкими являются специальности инженера-системохника и специалиста по информационным технологиям (ИТ). Хотя последние, чаще всего просто программисты. Существующие первые попытки подготовить специалистов более широкого профиля, например специализации подготовки CIO (Chief Information Officer), или MBI (Master of Business Information), следует приветствовать, но они в большей степени ориентированы на менеджеров ИТ, а не аналитиков.

Появились и первые “Школы аналитиков” (программа одной такой школы представлена на рис.6 и сайте www.bae.ru), но число их выпускников весьма не значительно для изменения ситуации.

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

Понятие онтологии и онтологического анализа вошли и в процедуры и стандарты моделирования бизнес-процессов. Ведь описание бизнес-процесса – это по сути структурирование данных и знаний. Так в группе стандартов IDEF, который является основным средством спецификации корпоративных информационных систем (КИC) и моделирования бизнес-процессов сегодня, имеется стандарт IDEF5 для описания онтологий.

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

Можно привести простейший алгоритм онтологического инжиниринга («для чайников»):

• выделение концептов — базовых понятий данной предметной области;
• определение «высоты дерева онтологий» – числа уровней абстракции;
• распределение концептов по уровням;
• построение связей между концептами — определение отношений и взаимодействий базовых понятий;
• консультации с различными специалистами для исключения противоречий и неточностей.

При явном интересе к онтологическому инжинирингу (системы ONTOLINGVA, Ontobroker, SHOE и другие) в настоящее время трудно назвать промышленные систем проектирования онтологий. Нами разработано несколько программных продуктов CAKE (Сомputer Aided Knowledge Engineering) [Воинов, Гаврилова, Данцин, 1996], ВИКОНТ — ВИзуальный Конструктор ОНТологий [Гаврилова, Лещева, 20000; Gavrilova, Fertman, 2001.] и VITA (VIsual onTology-based hypertext Authoring tool)[Gavrilova, Geleverya, 2001], позволяющих визуально проектировать онтологии различных предметных областей.

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

Онтологический подход к проектированию КИС позволяет создавать системы, в которых знания становятся «видимыми» и доступными для большинства сотрудников. На основе онтологий можно разрабатывать «карты знаний» (K-maps), которые указывают явно на источники знаний, т.е. где и у кого можно эти знания получить.

В результате интерес к системам СУЗ растет по следующим причинам:

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

Основным преимуществом онтологического инжиниринга в KM является целостный подход к автоматизации предприятия. При этом достигаются:

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

Стоит еще раз подчеркнуть, что онтология не только цель, но и средство формирования СУЗ.

Важность онтологического подхода в СУЗ обусловлена также тем, что знание, которое не описано и не тиражировано, в конечном счете становится устаревшим и бесполезным. Напротив, знание, которое распространяется, приобретается и обменивается, генерирует новое знание.

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

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

Автор выражает искреннюю благодарность Э.В. Попову за методическую и дружескую поддержку при работе над данной статьей.

Литература

Примечание

^[1] Работа выполнена при поддержке Российского Фонда Фундаментальных Исследований (грант 01-011-00224).

Версия для печати  |  Пользовательское соглашение