От инженерии знаний к онтологическому инжинирингу

    Введение. Статья посвящена введению в новое направление в методологии разработки интеллектуальных систем онтологическому инжинирингу (ОИ). Cегодня ведущей парадигмой структурирования информационного контента остаются онтологии или иерархичеcкие концептуальные структуры, которые формируются аналитиком на основе изучения и структурирования протоколов извлеченных знаний и документации (см. [Gruber, 1993; Попов, 2000; Гаврилова, Хорошевский, 2001; Гаврилова, 2004]). С методической точки зрения это один из наиболее "систематических" и наглядных способов. ОИ развивает основные положения инженерии знаний - науки о моделях и методах извлечения, структурирования и формализации знаний. Инженерия знаний - это ветвь искусственного интеллекта, в то время как ОИ сегодня охватывает более широкий круг приложений от систем управления знаниями до дистанционного обучения.
    Онтологический подход. Теория разработки онтологий активно развивается, но находится пока в стадии "первоначального накопления капитала". Онтология или концептуальная модель предметной области, состоит из иерархии понятий предметной области, связей между ними и законов, которые действуют в рамках этой модели.
    В работе [Гаврилова, 2004] была предложена следующая систематизация современных представлений и исследований в области онтологий. Рисунок 1 иллюстрирует основные принципы возможных классификаций онтологий:

по типу отношений
    - Таксономия - ведущее отношение "kind-of" ("is-a")
    - Партономия - ведущее отношение "имеет частью" ("состоит", "has part")
    - Генеалогия - ведущее отношение "отец-сын" ("потомок-предшественник")
    - Атрибутивные структуры
    - Причинно-следственные - ведущее отношение "if-then"
    - Смешанные онтологии - онтологии с другими типами отношений

по владельцу или пользователю
    - Индивидуальные (личные),
    - Групповые (коллективные):

Принадлежат стране,

Принадлежат сообществу (напр. научному),

Принадлежат компании или предприятию;
    - Общие (всеобщие).

по языку описания
    - Неформальные,
    - Формализованные,
    - Формальные - на языках RDFS,OWL, DAML+OIL и др.

по области применения
    - Наука,
    - Промышленность,
    - Образование и др.

по цели разработки
    - Для обучения,
    - Для исследований,
    - Для менеджмента,
    - Для обмена знаниями,
    - Для электронного бизнеса. 

Рис 1. Классификации онтологий

Эти классификации можно дополнить еще одной [Mizogushi, Bourdeau, 2000] согласно которой все онтологии делятся на
    - "весомые" онтологии (Heavy-weighted), содержащие аксиомы и
    - "легкие" (Light-weighted), их не содержащие.
    Иначе  - весомые онтологии,
               - легкие онтологии,
               где
    O- онтология,
    С - совокупность концептов предметной области,
    R - совокупность отношений между ними,
    A - набор аксиом (законов и правил, которые описывают, как законы и принципы существования концептов).
    Около 80 % разработанных онтологий относятся к "легким".
    Пополнять и изменять эту схему можно и далее, так как взгляды исследователей эволюционируют, и период "бума" онтологий продолжается уже более 5 лет.
    Структура онтологического инжиниринга. Онтологический инжиниринг как теория и технологии разработки онтологий активно развиваются [Mizogushi & Bourdeau, 2000; G?mez-P?rez, Fern?ndez-L?pez, Corcho, 2004] . Обобщая накопленный опыт можно предложить следующие разделы для представления ОИ (рис.2): 

Рис.2. Онтологический инжиниринг

  A. Разработка онтологий
               A.1.Извлечение знаний
                     - Теоретические аспекты
                     - Практические методы
               A.2.Структурирование знаний
                     - Стратегии
                     - Модели
                     - Алгоритмы
               А.3.Формализация
                     - Языки
                     - Редакторы
                     - Системы
               B. Применение онтологий
               В.1.СУЗ (Системы Управления Знаниями)
               В.2.Дистанцинное обучение
               В.3.Semantic Web
    Следует констатировать, что основные успехи лежат в области А3 и А4 - т.е. технологии, в то время как методология (А1 и А2) находится в зачаточном состоянии. В последнее время стало очевидным, что для промышленной разработки СУЗ уже недостаточно наличия формализованных языков (RDF, RDFS, OWL и др.) и систем (PROT?G?, APPOLLO, и др.), отвечающих на вопрос "КАК представить онтологию в сети?".
    На рынке программных средств достаточно активно продвигаются более 50 редакторов онтологий (см. таблицу 1).

Кроме этого на начальной стадии разработки онтологий хорошо себя показали и системы класса "mind mapping", например

Inspiration 7.6

Map it! 2003 (by Tony Buzan)

MindMapper 4.2. Pro

MindGenius Business 2005

Visual Mind 7

Mind Pad 1.1

Mind manager

The Brain

Однако самые изощренные редакторы и инструменты не могут выполнить содержательный анализ предметной области и креативный синтез онтологических структур. Сегодня необходимы практические рекомендации и технологии в областях A1 и A2, для получения ответа на вопросы: "ЧТО отражают знания, представленные в онтологии?" и "КАК их наглядно отобразить?".
    Методология формирования онтологий в системе PROTEGE
    Protege - это одна из наиболее популярных систем работы с онтологиями, созданная в Стэнфордском университете (США). По версии разработчиков системы Prot?g? все понятия предметной области делятся на классы, подклассы, экземпляры. Экземпляры могут быть как у класса, так и подкласса и описываются они фреймом [Минский, 1979]. Разработка онтологий для PROTEGE состоит из 5 шагов [Noy, 2001]:
    1. Выделение области (масштаба) онтологии, иначе определение границ онтологии.
    2. Определение классов;
    3. Организация иерархии классов;
    4. Формирование фреймов для описания классов, подклассов, экземпляров, через определение слотов, т.е. свойств;
    5. Определение значений;
    Protege предлагает нисходящую стратегию проектирования онтологий (сверху вниз). Существуют и восходящие стратегии. Возможно комбинирование стратегий.
    Узлы-братья в онтологии должны находиться на одном уровне. Братьев должно быть не меньше двух и не больше двенадцати, иначе по мнению разработчиков Prot?g?, можно выделить еще один подкласс.
    Слот следует относить к самому высокому классу в иерархии.
    Слоты делятся на:

Внутренние (определяются внутренним свойством объекта. Например, у фрейма "вино" - вкус).

Внешние (определяются внешним свойством объекта. Например, у "вина" - название).

Части (например "Содержание сахара в вине").

Другие.
Разработчики Protege считают, что нет правильного способа создания онтологии, так как онтология - это взгляд аналитика, т.е. всегда субъективна.
    Когнитивно-перцептивный подход к онтологическому инжинирингу. Рассмотрение основных направлений развития методологии ОИ, в том числе
    - Методов извлечения знаний,
    - Алгоритмов категоризации и структурирования (образование концептов и выявление связей), выходят за рамки данной статьи. Рассмотрим только некоторые аспекты непосредственного визуального дизайна онтологий. Для этого предлагается использовать методы гештальт-психологии для формирования "онтологического гармонии". Ранее [Гаврилова, 2003] уже был предложен "простой рецепт" создания онтологий для новичков, который вполне согласуется и с подходом группы PROT?G?. Последняя версия рецепта содержит 5 шагов [Gavrilova, Laird, 2005]:
    1. Формирование глоссария предметной области.
    2. Установление связей между понятиями глоссария и их визуализация.
    3. Категоризация понятий и формирование мета-понятий (снизу-вверх).
    4. Детализация (сверху-вниз).
    5. Ре-инжиниринг (уточнение, разрешение противоречий, синонимии, избыточности, перестройка, дополнение).
Представляется целесообразным применить некоторые результаты гештальт-психологии для шагов 2 - 5. Автор гештальт психологии Макс Вертгеймер так сформулировал основной принцип хорошего гештальта (хорошей формы) или закон прегнантности:

    "Организация любой структуры в природе или в сознании должна быть настолько хороша (регулярна, полна, сбалансирована или симметрична), насколько позволяют существующие условия". 
    Также полезными могут и другие когнитивно-перцептивные законы :
    o Закон близости - визуальные стимулы (объекты), находящиеся близко друг от друга воспринимаются как единое целое.
    o Закон сходства - вещи, обладающие одинаковыми свойствами. обычно воспринимаются как нечто единое (цельное).
    o Закон включения В.Келера - есть тенденция воспринимать только большую фигуру, а не ту меньшую которую она включает.
    o Закон парсимонии - самый простой пример является самым лучшим, известен как принцип "бритвы Оккама": "не нужно умножать сущности без необходимости".
    Попытаемся переформулировать эти законы для практического инженера по знаниям. Основная гипотеза: " Гармония = концептуальный баланс + ясность".
    При этом концептуальный баланс подразумевает, что
        - Понятия одного уровня иерархии связываются с родительским концептом одним и тем же типом отношения (например, "класс-подкласс" или "часть-целое").
        - Глубина ветвей онтологического дерева должна быть примерно одинаковая (±2 ).
        - Общая картинка должна быть довольно симметричной.
        - Перекрестные ссылки должны быть по возможности исключены.
    Ясность включает
        - Минимизацию. Так максимальное число концептов одного уровня или глубина ветви не должна превышать знаменитое число Ингве-Миллера (7±2) [Miller,1956] .
         Прозрачность для чтения. Тип отношений должен быть по возможности очевиден, так чтобы не перегружать схему онтологии лишней информацией и опускать названия отношений. 

Рис.3. Принцип хорошего гештальта

Иллюстрация принципа хорошего гештальта представлена на рис.3. Трудно не согласиться с более "правильной" формой онтологии A по сравнению с ошибками в структурировании онтологии B.

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

Литература
    1. Вертгеймер М. 1987. Продуктивное мышление. М., Прогресс.
    2. Гаврилова Т.А., Хорошевский В.Ф., 2001. Базы знаний интеллектуальных систем. Учебник.- Спб, Изд-во "Питер".
    3. Гаврилова Т.А. Онтологический подход к управлению знаниями при разработке корпоративных информационных систем. - Ж. "Новости искусственного интеллекта", N2, 2003. - с.24-30.
    4. Гаврилова Т.А., 2004. Управление знаниями: ЧТО ДЕЛАТЬ?// Cб. докладов Седьмой научно-практической конференции "Реинжиниринг бизнес-процессов на основе современных информационных технологий. Системы управления знаниями" (РБП-СУЗ-2004). М. - с.61-67.
    5. Минский М. Фреймы для представления знаний. - М., Энергия, 1979.
    6. Попов Э.В., 2001. Корпоративные системы управления знаниями. Ж. "Новости ИИ", N1.
    7. G?mez-P?rez, A., Fern?ndez-L?pez, M., Corcho, O., 2004. Ontological Engineering with examples from the areas of Knowledge Management, e-Commerce and the Semantic Web, Springer.
    8. Gavrilova, T., Laird, D., 2005. Practical Design Of Business Enterprise Ontologies // In Industrial Applications of Semantic Web (Eds. Bramer M. and Terzyan V.), Springer. - pp.61-81.
    9. Gruber, T., 1993. A translation approach to portable ontology specifications. Knowledge Acquisition , Vol. 5, 199- 220.
    10. McComb D., 2004. The CIO's Guide To Semantics © Semantic Arts, Inc. , www.semantic-conference.com
    11. Miller, G., 1956. The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information. The Psychological Review, vol. 63, 81-97.
    12. Mizogushi, R. and Bourdeau J., 2000. Using Ontological Engineering to Overcome Common AI-ED Problems // International Journal of Artificial Intelligence in Education, volume 11, 1--12.
    13. Noy N., McGuinness D. Ontology Development 101 : A Guide to Creating Your First Ontology.- Knowledge Systems Lab, Stanford, 2001.

Гаврилова Т.А.

РЕИНЖИНИРИНГ: В ЧЕМ ЕГО ПОЛЬЗА?

Автор статьи: Станислав Черемных, доктор технических наук, профессор.Финансовой Академии при Правительстве Российской Федерации. С автором можно связаться по электронной почте st_st_cher@mtu-net.ru

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

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

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

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

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

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

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

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

• Методология структурного анализа и проектирования (SA/SD). Эта методология основана на классической и весьма успешной методологии структурного проектирования программного обеспечения и информационных систем (ИС). Так как в разработке прикладных программ и ИС приходится постоянно иметь дело с различными информационными процессами, то неудивительно, что разработанные для этого методологии оказались вполне применимыми и для моделирования бизнес-процессов.
• Методология SADT представляет собой дальнейшее развитие методологии структурного анализа и проектирования.
• Методология IDEF. Это, пожалуй, наиболее глубоко проработанная и наиболее обширная методология, которая позволяет описывать не только бизнес-процессы, но и функциональные блоки (например, маркетинг или финансы), различные объекты в компании и действия над ними (например, весь комплекс процессов обработки и выполнения заказа клиента), а также состояние и динамику развития бизнес-единиц компании и компании в целом. Методология IDEF состоит из 14 компонент, наиболее важными из которых являются IDEF0 (методология моделирования функциональных блоков); IDEF1 (методология моделирования информационных потоков в компании); IDEF2 (методология моделирования динамики развития компании); IDEF3 (методология документирования бизнес-процессов в компании); IDEF4 (методология описания различных объектов в компании и действий над ними); IDEF5 (методология описания текущего состояния компании и тенденций его изменения)

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

После формирования рабочей группы необходимо подготовить план работ по реинжинирингу бизнес-процессов с тем, чтобы начать с оптимизации бизнес-процессов, наиболее значимых для конкурентоспособности, прибыльности, эффективности и стоимости компании (чтобы максимизировать эффект от реинжиниринга бизнес-процессов). При этом необходимо помнить, что, согласно принципу Парето, 20% бизнес-процессов в компании вносят 80% вклада в конкурентоспособность, прибыльность, эффективность и стоимость компании.

После этого необходимо подготовить подробное описание наиболее значимых бизнес-процессов в соответствии с используемой методологией. Обычно для этого используются специализированные программные средства, использующие выбранную методологию (например, BPWin, Design/IDEF, ERWin и т.д.). Это описание называется описанием текущего состояния бизнес-процессов (“as is”).

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

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

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

После этого необходимо лишь реализовать разработанный план, а затем повторять реинжиниринг по мере необходимости (т.е. по мере существенного изменения внутренних или внешних условий).