Содержание к диссертации
Введение
Глава 1 Методы и инструменты инжиниринга предприятий и проектирований информационных систем управлений на основе современного архитектурного подхода и перспективы применения онтологического моделирования 10
1.1 Методы и инструменты анализа и моделирования архитектуры трансформирующихся предприятий 10
1.2 Анализ применяемых методологий и технологий моделирования предметной области организации и её информационной системы 19
1.3 Проблематика развития и проектирования интегрированных информационно-аналитических систем организации 28
1.4 Онтологическое моделирование как способ описания предметной области организации 35
1.4.1 Понятие и структура онтологии 35
1.4.2 Классификация и области применения онтологии 37
1.4.3 Языки описания онтологии 40
1.4.4 Инструменты инженерии онтологии 44
1.5 Перспективы применения онтологии при разработке концептуальных описаний предметной области организации 45
Выводы Главы 1 47
Глава 2 Онтологический инжиниринг в проектировании информационно-аналитических систем 49
2.1 Метамодель предметной области организации на основе комплекса онтологических моделей 49
2.2 Концептуальное представление предметной области организации и её информационной системы на основе онтологической модели 52
2.3 Онтологическое моделирование бизнес-среды организации 67
2.4 Онтологический инжиниринг процедур и систем поддержки принятия решений 73
2.5 Исследование инструментальных возможностей и визуальных представлений комплекса онтологических моделей предметной области организации 79
2.5.1 Инструментальная реализация онтологии предметной области организации и ее информационной системы 79
2.5.2 Разработка онтологии бизнес-среды организации 86
2.5.3 Реализация онтологии процедур и систем поддержки принятия решений 91
Выводы Главы 2
Глава 3 Методические положения проектирования информационной системы организации на базе онтологических моделей 95
3.1 Методические положения по проектированию информационных систем на основе комплекса онтологических моделей предметной области организации 95
3.2 Формирование аналитическихприложений с помощью онтологической модели на-примере процедур поддержки принятия решений в информационно-аналитических системах 103
3.3 Оценка результативности и эффективности проектирования информационных систем на основе комплекса онтологических моделей предметной области организации 108
Выводы Главы 3 117
Заключение 119
Список используемой литературы
- Анализ применяемых методологий и технологий моделирования предметной области организации и её информационной системы
- Классификация и области применения онтологии
- Концептуальное представление предметной области организации и её информационной системы на основе онтологической модели
- Формирование аналитическихприложений с помощью онтологической модели на-примере процедур поддержки принятия решений в информационно-аналитических системах
Анализ применяемых методологий и технологий моделирования предметной области организации и её информационной системы
Как дисциплина информационный менеджмент он возник на- стыке отрасли информационных технологий и практического менеджмента в результате решения задач управления информационными системами компаний и организаций. По существу информационный менеджмент не имеет устоявшейся терминологии и ставших классическими решений. Вследствие этого, специалисты часто используют не только разную терминологию, но и различным образом толкуют задачи информационного менеджмента и методологию их решения. Для целей настоящего исследования будем понимать информационный менеджмент как совокупность методов и средств управления информацией и управление с помощью информации деятельностью предприятия или организации [25]. Теоретические и методологические подходы информационного менеджмента опираются на концептуальное представление организации в виде функционирующей бизнес системы в условиях динамично изменяющейся внешней среды. Деятельность предприятия связана с непрерывными изменениями, обусловленными подвижностью его стратегии. Стало общепризнанным, что стабильная бизнес-среда перестала существовать [30]. Изменения стратегии организации и последующие изменения в ее бизнесе непосредственным образом влияют на информационную систему организации, вызывая определенные изменения. Считается, что ИТ-стратегия предприятия должна вытекать из стратегии предприятия [85].
На практике это требует обеспечения сопоставимости и преемственности бизнес-стратегии и ИТ-стратегии предприятия на основе моделей стратегического соответствия, постоянного реинжиниринга предприятия и его информационной системы, а также реализации ИТ-стратегии через ИТ-инфраструктуру на всех уровнях управления. Как говорится в [20], существует определенная иерархия стратегий в организации. Верхний уровень представляет собой корпоративную стратегию, средний уровень - это стратегии бизнеса, бизнес-единиц, входящих в организацию. Нижний уровень - это функциональные стратегии. В данном контексте информационная стратегия является одной из функциональных стратегий организации. Информационная стратегия определяется исходя из идентификации и определения основных возможностей для бизнеса от использования ИТ.
Существующие сложные информационные системы организации представляют собой многоуровневый комплекс подсистем, состоящих из приложений различного уровня. Для эффективного управления информационной системой организации необходимо производить проектирование системы «сверху вниз», учитывая влияние стратегии на предоставляемые организацией бизнес-сервисы, что должно находить свое отражение в автоматизируемых процессах. В настоящее время в информационном менеджменте [26] широко распространено мнение о том, что ИТ-стратегия предприятия не может быть разработанаїи реализована-в отрыве от стратегии предприятия в целом, и должна естественным образом следовать из стратегии бизнеса.
Так, Б.А. Позин считает: «По существу, ИТ-стратегия- представляет собой среднёсрочныйшлан развития информационных технологий; компании для обеспечения заданных показателей бизнеса;... современнымтребованием: бизнеса; к ИТ становится необходимость непосредственного влияния ИТ наг результативность бизнеса; прежде? всего- на тактическом и стратегическом уровнях управления.» [58], При этом ИТ-стратегия должна быть неразрывна; с бизнес-стратегией организации1: И это, в свою очередь, предопределяет развитие ИТ-инфраструктуры и проектирование «сверху вниз». В то же время, ИТ-стратегия предприятиядолжнабыть гибкойи восприимчивой к изменениям среды, в которой функционирует организация. Это означает, что информационные системы организации должны быть подготовлены к постоянному реинжинирингу. Реинжиниринг информационной системы организации должен иметь упорядоченный характер и подчиняться единой стратегии:
Благодаря этому комплексному подходу к проектированию представляются широкие возможности для адаптивной перестройки ИТ-стратегии в соответствии с изменениями стратегии бизнеса. При этом ИТ-стратегия должна; иметь целостный, неразрозненный характер, и отвечать, в первую очередь, будущим потребностям. бизнеса, а не быть: подчиненной текущему или предыдущим состояниям/ ИТ-инфраструктуры организации, или потребностям отдельных бизнес-приложений. В том случае, если это складывается противоположным образом, то системный архитектор сталкивается с несколькими основными проблемами; среди которых: можно выделить проблемы координации деятельности и интеграции различных информационных систем, а также проблемы описания предметной области для проектирования более сложных интегрированных информационных систем; охватывающих не только моделирование и автоматизацию бизнес-процессов.
Эффективное планирование и реализация ИТ-стратегии сегодня связываются со сквозным сервисно-ориентированным проектированием (ССП) на основе архитектурного подхода [7].
ССП позволяет выстраивать целостный подход к проектированию информационной системы - от организации в целом и выделения бизнес-сервисов до ее информационной системы и отображения бизнес-сервисов в прикладные ИТ-сервисы.
Фундамент для полноценного сквозного сервисно-ориентированного проектирования обеспечивает архитектурный подход и специальные методы и модели анализа и синтеза сервисной бизнес-архитектуры и ее информационной инфраструктуры [7].
Таким целям служит «Enterprise Architecture» (ЕА, Архитектура Предприятия, АП). В самом общем виде под архитектурой предприятия понимается всестороннее: и-исчерпывающее описание всех его ключевых элементов и межэлементных отношений» Первоначально концепция архитектуры предприятия была создана для целей проектирования информационных систем, в дальнейшем сфера ее применения расширилась до области деятельности бизнес-архитекторов. Согласно международному стандарту ISO 15704" [101] архитектура предприятия: должна включать роль людей; описание процессов (функций и поведение), и представление всех вспомогательных технологий на протяжении всего, жизненного цикла? предприятия; Архитектура предприятия; в соответствии с моделью стратегического соответствия; выстраивается от стратегии бизнеса к ИТ-стратегии и исполняемымбйзнес-процессам;
В настоящее время сложились, различные концепции трактовки; архитектуры; предприятия. Фактическим стандартом: в- области проектирования: архитектуры предприятия стала архитектура; предприятия по Джону Захману; представившему архитектуру- предприятия в виде матрицы, в: которой основные; аспекты или точки зрения; представлены как оси, по которым участники процесса- проектирования рассматривают одни и те же категории;информации на-различных уровнях абстракции и детализации. Другие авторы рассматривая концепцию архитектуры предприятия, делают вывод что она представляет собой способ объединения и: синхронизации функциональных и бизнес-потребностей . организаций с возможностями информационных технологий в условиях их возрастающей сложности [26].
Данный подход представляет собой методологию комплексного описания информационной инфраструктуры предприятия, позволяющую собрать воедино различные описания как всего предприятия, так и его частей. Концепция архитектуры предприятия по Захману [93]предоставляет возможность описать предприятие в целом; выведя из такого описания логическим . образом архитектуру требуемой информационной инфраструктуры.
Захман признал, что все участники рассматривают одни и те же категории информации, представленные в колонках в концепции. Основная идея заключается в том, чтобы обеспечить возможность последовательного описания каждого отдельного аспекта системы в координации со всеми остальными. Для любой достаточно сложной системы общее число связей, условий и правил обычно превосходит возможности для одновременного рассмотрения: Модель представлена в виде таблицы, имеющей пять строк и шесть столбцов. Аспекты или: точки зрения представлены, как ряды в матрице (см. Приложение 1). Перспективы (строки в таблице) могут, в частном случае, соответствовать различному уровню управления предприятием, еслиг речь идет об архитектуре предприятия, или использовании информационной, системы. Две верхние строки соответствуют наиболее общим представлениям и достаточно широко описывают существующее окружение, планы и цели. В применении к деятельности предприятия верхняя строка - «Контекст» - соответствует уровню интересов высшего руководства и собрания акционеров. Второй уровень соответствует интересам бизнес-менеджеров и владельцев процессов. Третий уровень - это уровень, на котором бизнес-менеджеры, бизнес-аналитики и менеджеры, отвечающие за ИТ, должны работать вместе. Уровни с четвертого и далее описывают детали, которые представляют интерес для проектировщиков и разработчиков. На каждом из этих уровней участники, рассматривают одни и те же категории вопросов, соответствующие столбцам в таблице, но с различным уровнем абстракции и детализации. В содержание этих колонок входят: - используемые данные (что-), процессы и функции (как-),
Первая строка соответствует уровню планирования бизнеса, в целом, то есть отражает бизнес-среду предприятия. На этом уровне вводятся достаточно общие основные понятия, определяющие бизнес, такие как продукты и услуги, клиенты, расположение объектов бизнеса, а также формулируется бизнес-стратегия. Фактически, данная строка определяет контекст всех последующих строк. Вторая строка (концептуальная модель) предназначена для определения в терминах бизнеса структуры организации, ключевых и вспомогательных бизнес-процессов. Третий уровень (логическая модель) соответствует рассмотрению с точки зрения системного архитектора. Здесь бизнес-процессы описываются уже в терминах информационных систем, включая различные типы данных, правила их преобразования и обработки для выполнения определенных на уровне 2 бизнес-функций. На четвертом уровне -технологической или физической модели - осуществляется привязка данных и операций над ними к выбранным технологиям реализации. Например, здесь может быть определен выбор реляционной СУБД, или средств работы с неструктурированными данными, или объектно-ориентированной среды. Пятый уровень соответствует детальной реализации системы, включая конкретные модели оборудования, топологию сети, производителя и версию СУБД, средства разработки и собственно готовый программный код. Последний, шестой уровень описывает работающую систему. На этом уровне могут быть введены, в том числе, такие объекты, как инструкции для работы с системой, фактические базы данных. Свойством предложенной модели является необходимость последовательного перехода при углублении детализации рассмотрения.
Классификация и области применения онтологии
SWOT-анализ позволяет определить причины эффективной или неэффективной работы компании на рынке и представляет собой сжатый анализ маркетинговой информации на основании которого делается вывод о том, в каком направлении организация должна развивать свой бизнес. Классический SWOT-анализ предполагает определение сильных и слабых сторон в деятельности фирмы, потенциальных внешних угроз и благоприятных возможностей и их оценку относительно стратегически важных конкурентов. Фактически, анализ дает представление о положениях, в которых организация функционирует, что соответствует. столбцу «Данные» уровня «бизнес-среды» рамочной схемы архитектуры предприятия. Некоторыми авторами отмечается, что при SWOT-анализе после определения критических факторов проекта и ключевых факторов успеха на основе анализа формируются основные цели, разрабатываются стратегии и рассчитываются финансовые показатели. Это говорит о взаимосвязи с такими осями рамочной схемы как «Мотивация» (Перечень бизнес целей и стратегий) и ключевыми показателями эффективности.
Говоря о GAP-анализе, как правило, понимают набор мероприятий, позволяющих делать выводы о несоответствии внутренней среды маркетинга внешнему окружению. Это может быть несоответствие ассортимента структуре спроса, несоответствие продукции аналогичной продукции конкурентов. Цель GAP-анализа состоит в том, чтобы выявить те рыночные возможности, которые могут стать для компании эффективными рыночными преимуществами. С помощью данного анализа определяется перечень бизнес мероприятий, что соответствует квадранту «Перечень бизнес мероприятий» рамочной схемы архитектуры предприятия, который находится в непосредственной связи с квадрантом «Перечень бизнес целей и стратегий».
Матрица Бостонской Консалтинговой Группы (BCG) разработана одной из крупнейших американских консалтинговых компаний в целях определения базового подхода для управления портфелем продукции. Суть матрицы составляют два базовых параметра, по которым ведется анализ продукции: это относительная (относительно конкурентов) доля рынка и рост самого рынка. Основная проблема состоит в том, что эта матрица приводит к сильному упрощению сложного процесса принятия решений. Однако в какой-то мере матрица описывает перечень важных факторов для предприятия, то есть ось данных рамочной схемы АП.
PEST- это аббревиатура для Политических, Экономических, Социальных и Технологических факторов, которые используются, чтобы оценить рынок для организационной или бизнес-единицы. PEST-анализ - полезный инструмент понимания рынка, позиции компании, потенциала и направления бизнеса. Данный инструмент описывает перечень важных факторов для предприятия, то есть ось данных рамочной схемы АП.
Как видно из выше изложенного описания, каждая из этих моделей предназначена для описания определенного рода взаимодействия с внешней средой и анализ построенной модели позволяет получить результаты, применимые для определенного рода задач. Однако к недостаткам указанных моделей стоит отнести тот факт, что каждая из них предназначена лишь для своей, как правило, довольно узкой задачи. При этом отсутствует технология их общего совместного применения для целей управления. Кроме того, каждая из разрабатываемых таким образом моделей использует свой собственный терминологический аппарат, не коррелирующий с понятиями и терминами других разрабатываемых моделей. Отсутствие единства терминологии ведет к невозможности полноценного комплексного ее применения, так как этому препятствует невозможность проследить перекрестное взаимодействие факторов различных моделей.
Кроме того, данные модели в их классическом виде представляют собой вербальное и слабо формализованное описания. Данные модели не имеют инструментальной реализации, несмотря на то, что активно применяются в практике стратегического менеджмента. Это является препятствием для автоматизации процесса построения и анализа полученных моделей. В условиях отсутствия машинно-читаемости данных моделей затрудняется их обработка при проектировании информационно-аналитической системы организации. Далеко не все модели имеют инструментальную реализацию, и при этом отсутствует комплексное инструментальное решение- для построения описанных моделей во взаимодействии.
Модели внутренней структуры организации, как правило, отражают организационную структуру, либо особенности процессуального взаимодействия в ходе осуществления деятельности организации. Среди них выделяют следующие:
Указанные модели описывают внутреннюю структуру предприятия в статике. В качестве особенностей таких моделей следует отметить, что они обладают большой степенью структурированности и однозначности. Такие модели в большой степени могут быть пригодны для реализации в информационных системах, автоматизации их обработки и трансляции в машинно-читаемые форматы.
В части архитектурной работы с бизнес-процессами сегодня широко используются методологии и технологии моделирования бизнес-процессов, языки организационного моделирования, при этом язык BPML является стандартом, а также CASE-средства и язык UML, поддерживающие автоматизацию исполняемых бизнес-процессов на технологическом уровне рамочной схемы архитектуры предприятия.
В настоящее время разработано немало различных методологий проектирования информационных систем. При проектировании корпоративных информационных систем разработчик и заказчик нуждаются в комплексном описании и планировании развития организации. Это необходимо для понимания того, что данная организация представляет собой в настоящий момент, чтобы определить рациональный порядок ее устройства и далее - приступить к ее планомерному развитию или трансформации с учетом всех важных обстоятельств. Как было сказано выше, существующие методологии не в полной мере отвечаю потребностям проектирования современных систем. Рассмотрим подробнее их недостатки.
Методология SADT (аббр. от англ. Structured Analysis and Design Technique) — это методология структурного анализа и проектирования, интегрирующая процесс моделирования, управление конфигурацией проекта, использование дополнительных языковых средств и руководство проектом со своим графическим языком Распространение SADT привело к стандартизации и публикации ее части, предназначенной для функционального моделирования, как методологии и стандарта функционального моделирования и описания бизнес-процессов IDEF0 - одного из международных стандартов методологий семейства IDEF, которое является стандартом функционального моделирования. С помощью наглядного графического языка IDEF0, изучаемая система предстает перед разработчиками и аналитиками- в виде набора взаимосвязанных функций. Как правило, моделирование средствами- IDEF0 является первым этапом изучения любой системы [12].
Особенностью нотации IDEF0 является возможность декомпозировать процессы на подпроцессы до необходимого уровня детализации и, таким образом, строить иерархические модели бизнес-процессов. Нотация IDEF0 служит,, прежде всего, для описания состава структурированных исполняемых процессов, протекающих в рассматриваемой системе, а не их последовательности. Поэтому нотация 1DEF0 в основном используется для создания верхнего уровня модели бизнес-процессов [104].
IDEF1 Extended) — Data Modeling — методология построения реляционных структур (баз данных), относится к типу методологий «Сущность-взаимосвязь» (ER — Entity-Relationship) и, как правило, используется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе. Основным преимуществом IDEF1X, по сравнению с другими многочисленными методами разработки реляционных баз данных, является жесткая и строгая стандартизация моделирования. Установленные стандарты позволяют избежать различной трактовки построенной модели, которая несомненно является значительным недостатком классической ER „ Однако данная методология направлена строго на описание структуры реляционной базы данных информационной системы, проектируемой на основе прочих моделей, то есть является узконаправленной.
Методология IDEF3 моделирования документирования процессов, происходящих в системе, предоставляет механизм документирования и сбора информации о процессах. IDEF3 показывает причинно-следственные связи между ситуациями и событиями в понятной эксперту форме, используя структурный метод выражения знаний о том, как функционирует система, процесс или предприятие [66] IDEF3 состоит из двух методов: Process Flow Description (PFD) - Описание технологических процессов, и Object State Transition Description (OSTD) - Описание переходов состояний объектов.
Концептуальное представление предметной области организации и её информационной системы на основе онтологической модели
В настоящее время широко используются базы данных, организации доступа к данным, в контексте интернет-среды и создание больших библиотек электронных коллекций. При этом осознается значение информационных систем для формального описания и хранения большого числа фрагментов (модулей) знания, которые могут представлять собой понятия некоторой области ізнаний, системы моделей, схемы баз данных, параметрические запросы, типы объектов и компоненты систем.
В последние годы в среде World Wide Web для работы с формально описанными знаниями все больше используется система Ontolingua, разработанная в Knowledge System Laboratory (KSL) в рамках отделения Информатики Стэнфордского университета. Структурной единицей знания в этой системе является онтология. Язык Ontolingua использует принципы объектно-ориентированного подхода и является расширением компьютерно ориентированного языка Knowledge Interchange Format (KIF) для обмена знаниями и взаимодействия между программами.
KSL Ontolingua Server предоставляет среду для совместного просмотра, создания, редактирования, модификации и. использования онтологии в среде Internet. Сервер в настоящее время поддерживает более 150 активных пользователей и содержит множество библиотек по различным областям знаний, включая элементарную геометрию и теоретическую механику. После того, как в феврале 1995 года было объявлено о работе сервера, он стал использоваться большим числом рабочих групп со всего мира для создания онтологии и доступа к ним. Имеется множество проектов, ориентированных на использование системы Ontolingua.
Система Ontolingua эксплуатируется уже несколько лет и опыт ее работы, принципы ее организации могут быть полезными как при проектировании электронных библиотек в среде Internet, так и при определении перспектив разработки систем основанных на знаниях. С другой стороны, система Ontolingua разрабатывалась как система, взаимодействующая с другими системами в Internet, и некоторые решения этой разработки предлагаются в виде стандарта. Учет этого стандарта представляется важным при разработке новых систем. Protege
Инструмент создания онтологии Protege был разработан Стэнфордским центром исследований биомедицинской информатики при факультете медицины Стэнфордского университета. Он представляет собой платформо-независимую расширяемую среду, позволяющую пользователю быстро и интуитивно приступить к созданию своих онтологии [54]. Процесс построения онтологии в системе состоит из создания следующих блоков:
Ограничения по слотам (также известных как аспекты/грани (slot facets), иногда называемые ограничения ролей). Онтология вместе с множеством индивидуальных экземпляров классов составляют базу знаний.
В этой системе онтология - формальное явное описание понятий в рассматриваемой предметной области (классов), свойств каждого понятия, описывающих различные свойства и атрибуты понятия- (слотов), и ограничений, наложенных на слоты (фацетов). Онтология вместе с набором: индивидуальных экземпляров классов образует базу знаний. Создание онтологии включает следующие этапы:
Для любой, предметной области может существовать бесчисленное количество онтологии; Система поддерживает множество онтологических языков и их сочетаний, основываясь на языках RDF, OWL и XML.
Данный инструмент создания онтологии поддерживает общую методологию построения онтологии, определяемую через иерархию классов, а так же настройку различного рода слотов для определения отношений классов и экземпляров классов.
Поставлена задача поиска новых методологических подходов и технологий к описанию архитектуры и информационной инфраструктуры организации, которые необходимы, для обеспечения связи с методологиями проектирования информационных систем транзакционного типа и являлись «навигатором» по различным моделям и языкам организационного моделирования, обеспечивали единство понятийного аппарата, были ориентированы на процесс принятия стратегических решений. Модели, методы и инструменты концептуального представления и комплексного описания предметной области организации и ее информационной системы на основе архитектурного подхода должны являться инструментом для системного архитектора, проектирующего информационные системы, обеспечивать координацию и регламент взаимодействия основных участников проекта автоматизации и служить общей понятийной базой для взаимодействия бизнеса, формулирующего стратегию, с аналитиками, разрабатывающими стратегию, и ИТ-инженерами, корректирующими информационную инфрастурктуру организации.
Данные инструменты должны обеспечивать взаимосвязь архитектурных моделей с приложениями в рамках процедуры формирования и принятия стратегических решений в информационно-аналитических системах и системах поддержки принятия решений.
Изученные в ходе настоящего исследования свойства онтологии позволяют утверждать, что они могут быть использованы в качестве инструмента концептуального описания предметной области предприятия. На основе произведенного исследования можно сделать вывод о том, что применение онтологического подхода предоставляет ряд возможностей при моделировании архитектуры предприятия для формализации базовых категорий предметной области организации с учетом сформулированных в п. 1.1. настоящего исследования требований:
Модель позволит целостно описать процесс принятия, решений, интегрирующий ИТ-сервисы на различных уровнях информационной системы - от транзакционных до аналитических.
Создание и применение онтологических моделей предметной области организации на основе рамочных схем позволит создать- предпосылки для формирования единой инструментальной среды моделирования организации и ее информационной системы, которая бы обеспечивала связь с другими-методологиями и технологиями проектирования. Их машинная реализуемость и универсальность форматов позволяют сделать вывод о возможности создания workflow-систем с функцией кодогенерации, либо интеграции с существующими системами.
Перспективным направлением можно считать рассмотрение организации в динамике на основе моделей предметной области организации. В теоретическом плане существуют концепции (framework), отражающие развитие организации по оси времени. Добавление хронологического фактора и динамических моделей в комплекс моделей на основе онтологии- позволит лучше изучить архитектурные модели организации. Построенные таким образом модели могут быть в перспективе применены как для корпоративных, так и для федеральных архитектур.
Формирование аналитическихприложений с помощью онтологической модели на-примере процедур поддержки принятия решений в информационно-аналитических системах
В результате была разработана онтология процедур принятия решений. Модель содержит классы, соответствующие основным фазам цикла управления согласно концепции ВРМ, а так же классы системы целей и стратегий, унаследованные с моделей верхнего уровня. Модель отражает взаимодействие базовых классов с классами «Средства и технологии», «Участники процесса» и «Информация».
Прикладная онтология может быть использована для разработки связанных аналитических приложений в ВРМ-системах, и выходом модели является функциональная структура приложения, инструментальная структура приложения, система ролей и прав доступа, а так же перечень используемой и хранимой информации. С учетом особенностей проектируемого приложения, устанавливается взаимосвязь с системой целей и стратегий организации, на показатели эффективности которых воздействуют стратегические решения.
Данное описание может служить для проектирования основных функциональных элементов проектируемой аналитической системы. Описанные методы реализации каждого этапа могут применяться для проектирования алгоритмов конкретных функциональных приложений в системах управления эффективностью бизнеса. Данное представление процесса принятия решений отражает его особенности: процесс является замкнутым, непрерывным и нелинейным. Онтология процесса принятия решений обеспечивает технологический переход к формированию информационной архитектуры приложений, сервисов и данных ИАС. При этом проектирование приложений происходит во взаимосвязи между этапами процесса принятия решений с постоянной ориентацией на стратегию и цели организации.
На этапе проектирования информационно-аналитической системы модель служит инструментом системного аналитика, и позволяет спроектировать не только приложения, но и индикаторные панели с выводом ключевых показателей эффективности.
На этапе разработки стратегии онтологическая модель, дополненная и проработанная системным аналитиком, может служить инструментом менеджера, и демонстрировать возможность управления темнили иными ключевыми показателями.
Инструментальная реализация онтологии предметной,области организации и её информационной системы
В ходе исследование была произведена инструментальная реализация построенных моделей с помощью инструмента инженерии онтологии. Были построены все три описанные онтологии.
В ходе инструментальной реализации мета-онтологии необходимо было выделить основные классы модели. Данные понятия были выделены в качестве базовых классов онтологии. На рисунке 31 приведена программная реализация базовых классов в среде моделирования онтологии Protege:
Производя исследования для онтологического инжиниринга, был сделан вывод, что бизнес-архитектура состоит из большого количества понятий, и является одной из ключевых составляющих архитектуры предприятия. Рассматривая её составляющие, можно выделить следующие элементы, представленные в виде подклассов в онтологии. На рисунке 32 представлена инструментальная реализация структуры класса «Бизнес-архитектура» онтологической модели. Ass«»ted Hteiarohy
На иллюстрации продемонстрировано, что данные экземпляры обладают слотом «Воздействует на», что отвечает общему смыслу Системы сбалансированных показателей. С помощью данного слота описано взаимодействие всех экземпляров для подклассов класса «Система показателей стоимости компании».
Были выделены подклассы онтологической модели для класса «Информационная» архитектура». В результате в онтологии класс «Информационная архитектура» состоит из следующих подклассов, представленных на рисунке 35:
Корпоративное_управление О Корпоративная_модель & О Система_показателей_стоимости_компании О Ценности_и_идеология_бизнеса
После описания с помощью данных слотов взаимодействие классов онтологической- модели появилась возможность перейти к описанию экземпляров классов. Был прописан ряд экземпляров для различных классов модели. В результате работы над моделью была сформирована типовая мета-онтология архитектуры предприятия.
Визуализация модели была реализована с помощью специального плагина к инструменту Protege под названием Jambalaya. С помощью данного инструмента был получен ряд представлений модели в различных форматах. В качестве исходного представления инструмент предлагает отображение классов верхнего уровня без отображения их внутренней структуры и связей. Данная визуализация представлена в Приложении 3.
Следуя одному из главных постулатов онтологического моделирования -представлять нужную информацию каждому потребителю - данная модель позволяет визуализировать внутреннюю структуру и связи тех элементов, которые интересны тому или иному потребителю информации (рис.40): owtThkig
С помощью инструмента можно декомпозировать ту или иную область модели, чтобы определить компоненты и их взаимосвязи в отдельной области архитектуры предприятия. Детализация класса «Бизнес архитектура» представлена в Приложении 4. В данном представлении показан класс «Бизнес-процессы» с отображением взаимосвязей. Данное представление является уровнем контекста диаграммы бизнес-процесса. Это является исходной информацией для моделирования бизнес-процессов традиционными средствами ВР-моделирования. При этом онтология позволяет параллельно с моделирвоанием бизнес процессов детализировать связанные классы: элементы организационной структуры, необходимые ресурсы, вид входных и выходных потоков, необходимое управляющее воздействие.
Взаимосвязи показывают как информационные сущности, так и физические. При достаточной проработке модели можно описать различные аспекты организации. Так, входной1 и выходной поток для бизнес-процесса в физическом смысле может представлять из себя материальные объекты. Для хранения и обработки их необходим склад, как сущность, и процесс складского обеспечения, как вспомогательный процесс для бизнес-процесса. Детализация данного процесса позволяет скорректировать стандартные связанные классы для процесса, уточняя структуру предприятия в организационном, функциональном и других аспектах.
