пятница, 30 сентября 2016 г.

Основы организационного бизнес-моделирования


Горелик С. Л.
Продолжаем серию публикаций по бизнес–инжинирингу (начало см. «Эмитент», выпуск 1/2001). В предыдущей публикации была показана роль бизнес-модели как инструмента повышения инвестиционной привлекательности за счет обеспечения прозрачности, предсказуемости и воспроизводимости бизнеса. В этой статье будут рассмотрены базовые понятия технологии бизнес-инжиниринга.

Парадигма бизнес-инжиниринга

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

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

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

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

На этом этапе бизнес-моделирования формируется общепризнанный набор основополагающих внутрифирменных регламентов:

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

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

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

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

Построение полной бизнес-модели компании




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



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

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


При этом происходит последовательное процессно-целевое описание компании (рис. 4).




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

Организационно-функциональная модель закрепляет бизнесы и функции за организационными звеньями. Отвечает на вопросы что, в каком подразделении (где) и кто именно делает в компании (и соответственно отвечает за это);

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

Количественная модель описывает бюджеты компании – поступление и выбытие денежных средств в ходе выполнения бизнес-процессов и возникающие при этом доходы и расходы. Отвечает на вопрос сколько необходимо финансовых ресурсов для обеспечения деятельности компании;

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

Бизнес-модель компании обеспечивает необходимую полноту и точность ее описания. С помощью бизнес-модели формируются все необходимые управленческие регламенты.
Именно этим достигается прозрачность, предсказуемость и воспроизводимость бизнеса, обеспечивая высокую динамику его развития, конкурентоспособность, а значит, в конечном счете, и инвестиционную привлекательность компании.



четверг, 29 сентября 2016 г.

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


    Введение. Статья посвящена введению в новое направление в методологии разработки интеллектуальных систем онтологическому инжинирингу (ОИ). 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.

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

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

    Татьяна Гаврилова


    Введение

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

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

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

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

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

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

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

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


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

     Рис 1. Роль структурирования в автоматизации

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

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

    1. Двойственность понятия «управление знаниями»

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

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

    Рис.2. Дуализм дисциплины “Управлеие знаниями”

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

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


    Рис.3. “Цветок“ информационных составляющих

    Традиционно проектировщики систем УЗ (СУЗ) ориентировались лишь на отдельные группы потребителей — главным образом, менеджеров. Более современные СУЗ спроектированы уже в расчете на целую организацию
    Из-за этого разнообразия СУЗ вынуждены интегрировать разнообразные технологии:
    • электронная почта и Интернет-ресурсы;
    • системы управления базами данных (СУБД) и сами базы данных (БД);
    • средства создания хранилищ данных (Data Warehousing);
    • системы поддержки групповой работы;
    • локальные корпоративные системы автоматизации;
    • системы документооборота и worlflow;
    • экспертные системы и базы знаний и др.
    При этом, ни одна из этих технологий (кроме последней) не включает «знания» в контексте интеллектуальных (экспертных) систем, т.е. баз знаний.
    Фактически УЗ – это модный лозунг в менеджменте и его связь с инженерией знаний (knowledge engineering) в настоящее время практически эфемерна. Нечеткость различий в понятиях «информация», «данные» и «знания» льет воду на мельницу спекуляций эту тему. Если трактовать информацию, как общий термин для всех информационных ресурсов предприятия (рис.4), то в реальности современные СУЗ занимаются проблемой организации только части информации, в основном документооборота в компании.

    Рис. 4. Основные типы информации в системах KM

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

    2. Корпоративная память и онтологии

    Программные инструментарии для создания хранилищ данных, которые работают по принципу центрального склада, были одним из первых предвестников СУЗ. Как правило, хранилища содержат многолетние версии обычной БД, физически размещаемые в той же самой базе. Когда все данные содержатся в едином хранилище, изучение и анализ связей между отдельными элементами может быть более плодотворным. В дальнейшем идея хранилища была развита в понятие корпоративной памяти (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. Пример визуального представления фрагмента онтологии

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

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

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

    Модуль 1. Введение в инженерию данных и знаний (12 часов, 8 практических тестов)
    • 1.1. Работа с информацией: данные и знания
    • 1. 3. Модели представления знаний
    • 1. 4. Работа с нечеткой информацией
    • 1. 5. Стратегии получения информации
    • 1. 6. Психологический аспект извлечения знаний и данных
    • 1. 7. Лингвистический и аспект извлечения знаний и данных
    • 1. 8. Методический аспект извлечения знаний и данных
     
    Модуль 2. Практическая инженерия знаний (16 часов, 10 практических тестов)
    • 2.1. Индивидуальные коммуникативные методы извлечения данных и знаний
    • 2.2. Групповые коммуникативные методы извлечения
    • 2.3.Текстологические методы
    • 2.4. Структурирование данных и знаний: объектно-структурный анализ
    • 2.5. Онтологии и визуальное моделирование
    • 2.6. Функциональные роли в коллективе разработчиков

    Рис.6 . Программа ШКОЛЫ АНАЛИТИКА

    Появились и первые “Школы аналитиков” (программа одной такой школы представлена на рис.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)

    Литература

    Гаврилова ТА., Хорошевский В.Ф. Базы знаний интеллектуальных систем / Учебник для вузов. – СПб, Изд-во “Питер”, 2000.
    Воинов А., Гаврилова Т. А., Данцин Е. Я., 1996. Язык визуального представления знаний и его место в САКЕ-технологии // Журнал Известия РАН, Теория и системы управления, N2. - c.146-151.
    Гаврилова Т.А., Лещева И.А., Лещев Д.В., 2000. Использование онтологий в качестве дидактического средства // ”Искусственный интеллект” N3. - с.34-39.
    Попов Э.В., 2001. Корпоративные системы управления знаниями. Ж.”Новости ИИ”,N1.
    Arpirez J., Gomez- Perez A., Lozano A., Pinto S. (ONTO) 2Agent: An ontology- based WWW broker to select Ontologies // Workshop on Applications of ontologies and Problem Solving Methods. ECAI’98.
    Borghoff U., Pareschi R., 1998. Information Technology for Knowledge Management. – Springer-Verlag, Bln.
    Gavrilova T., Geleverya T., 2001. VITA: Using PYTHON for Visual Design of Web-based Tutorials// Proc. of the Tenth International PEG Conference “Intelligent Computer and Communications Technology – Learning in On-Line Communities”, Tampere, Finland. - pp.44-50.
    Gavrilova T., Fertman V. One Approach to Visual Design of Intelligent Agents // Proceedings of the Second International Workshop of Central and Eastern Euope on Multi-Agent Systems, CEEMAS’01, Krakow, Poland, 2001. - pp.329-337.
    Gruber T. R.  A translation approach to portable ontologies. Knowledge Acquisition, 5(2):199-220, 1993.
    Guarino N., Giaretta P. Ontologies and Knowledge Bases: Towards a Terminological Clarification. Towards Very Large Knowledge Bases: Knowledge Building & Knowledge Sharing. // IOS Press. 1995. 25-32.
    Hinkelmann K. and Kieninger Th. Task-oriented web-search refinement and information filtering. DFKI GmbH, 1997.
    Kuhn O., Abecker A., 1998. Corporate Memories for Knowledge Management in Industrial Practice: Prospects and Challenges.
    Kuhn O., Becker V., Lohse V. and Ph. Neumann, 1994. Integrated Knowledge Utilization and Evolution for the Conservation of Corporate Know-How // ISMICK'94: Int. Symposium on the Management of Industrial and Corporate Knowledge
    Macintosh A., 1997. Knowledge asset management. // Airing. – №20, April.
    Malsch Th., Bachmann R., Jonas M., Mill U., and Ziegler S., 1993. Expertensysteme in der Abseitsfalle? - Fallstudien aus der industriellen Praxis. edition sigma, Reiner Bohn Verlag, Berlin.
    Nonaka I. and Takeuchi I., 1995. The Knowledge-Creating Company. New York, Oxford: Oxford University Press
    Piatetsky-Shapiro G. and Frawley W., eds., 1991. Knowledge Discovery in Databases. – AAAI/MIT Press.
    Tschaitschian B., Abecker A. and Schmalhofer, 1997. A. Putting Knowledge Into Action: Information Tuning With KARAT. // In 10th European Workshop on Knowledge Acquisition, Modeling, and Management (EKAW-97).
    Wiig, 1990. Expert Systems: A manager’s guide. – Geneva: The International Labour Office of the United Nations.

    Wiig К., 1996. Knowledge management is no illusion! // Proc. of the First International Conference on Practical Aspects of Knowledge Management. – Zurich, Switzerland: Swiss Informaticians Society



    Feature Comparison Matrix

    Картинки по запросу feature comparison matrix template

    What is a Feature Comparison Matrix?
    As the name specifies, it is a matrix which compares the availability of different Features of various Products of similar kind. 

    When do you need a Feature Comparison Matrix?
    • If you want to compare Features of various Products of similar class.
    • If you are working in Software Product Development Company, and you are part of a new Product Development Process. At that time, you need to do a Market Analysis & Industry Analysis to understand the Vendors (Competitors) who are providing similar kind of Products. As a result of your Market/Industry Analysis, you need to come up with a Feature Comparison Matrix which will show-case the various features offered by similar kind of Products and which all features exist in which Product.
    • If you are working in a Project, and the Project requires a specific 3rd Party Product to be integrated for a particular module. E.g.: If you are working in a "Treasury" Management System, and you require a 3rd party application for "Forex Pricing Engine". So you need to identify the Vendor's Products you are looking and go through the details of those products and prepare a Feature comparison Matrix, which can be used later for Vendor/Product Evaluation.
    How to prepare a Feature Comparison Matrix?
    Let's go through a sample Feature Comparison Matrix which I have created. 


    Pic: Sample Feature Comparison Matrix
    Steps:

    1.  Identify the Vendors, whose Products you will be comparing. To do this, go through various Analyst Sites to identify the Top Vendors who offer the similar kind of Products.

    E.g.: We would like to have a Product for "Mortgage Management System". Identify all Vendor Products and choose top 5 Vendor Products for comparison. 

    2.  Identify all possible Features present in all the Products, which should be a Super Set of Features. List these features Module-wise. If you are aiming for developing any Product, then Identify and list all possible Features you want to have in the Product and then compare the same with other Vendor Products.

    E.g.: Identify various Modules in a "Mortgage Management System", such as: Loan Origination, Loan Underwriting, Loan Closing and Loan Servicing. Then list out all possible features/requirements for each of the Modules.

    3.  List out all Vendor-Products and mark against the features which are available in that Product. Please refer to the above picture.

    Analyzing the Feature Comparison Matrix Result:

    1.  The last row (No. of Features Available out of 14) in the picture shows that:
    • There are total 14 features in the Matrix. Out of 14 features, how many features are present in each Vendor Product.
    • "Vendor 1 - Product 1" satisfies maximum number of features i.e. 10.
    • "Vendor 4 - Product 4" satisfies minimum number of features i.e. 5.
    2. The last column depicts the count of Vendor Products where a Particular Feature is available. 
    • "Feature - 11" is present in all the 4 Vendor Products.
    • "Feature - 2" is present in only one Vendor Product.

    These kind of analysis helps in understanding and identifying which Vendor Product meets to our expectation. While finalizing a particular Product, we need to consider the Product Pricing as well as a main criteria.

    Hope this article help you out in understanding the practical approach of a Feature Comparison Matrix. Do let me know you feedback through your comments.


    As We Work...We Learn...