Business Engineering Group | Главная страница Бизнес Инжиниринг Групп | Главная страница Написать письмо Написать письмо Карта сервера Карта сайта
Бизнес Инжиниринг Групп
ЧаВо Форум Контакты Прайс
ЧаВо
Форум
Контакты
Прайс
О фирме
Консалтинг
Обучение
Инструменты
Клиенты
е-Государство
Теория
Публикации
Комплекс ОРГ-МАСТЕР®ПРО

Сравнительный анализ программ для бизнес-моделирования

ОРГ-МАСТЕР vs АРИС, BPWin
ОРГ-МАСТЕР vs БИГ-Мастер МИНИ-МИДИ-МАКСИ
Сравнение 10.3 и ПРОФИ
ОРГ-МАСТЕР vs Прочие
Пользователи

Задайте нам вопрос

Имя:

Компания:

Телефон:

E-mail:

Вопрос:
Введите число на рисунке:
Ближайшие семинары
Современное организационное проектирование: это надо всем компаниям - этому нигде не учат! Только на семинарах «Бизнес Инжиниринг Групп»
подробнее подробнее...
Главная | Инструменты | Сравнительный анализ программ для бизнес-моделирования | ОРГ-МАСТЕР vs АРИС, BPWin

ПРИЛОЖЕНИЯ

Приложение 1. Сокращенная формализация компонент моделей ОРГ-Мастер

Модели, применяемые в ОРГ-Мастере для описания бизнес-систем и протекающих в них процессов, используют следующие основные компоненты.

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

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

<классификатор> ::= <имя классификатора> <список значений> [свойство] *)

<список значений> ::= <пусто> | <значение> | <список значений> <значение>

<значение> ::= <имя экземпляра сущности> [список значений]

<свойство> ::= ‘агрегация’|’композиция’|’обобщение’

*) аналогично категоризации BP-Win или отношениям для диаграмм классов в UML. В текущей версии ORG-Master не используется.

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

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

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

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

проекция ::= <имя классификатора1><имя классификатора2>[<тип связи> | <имя классификатора3>] <список пар>

список пар::= <пусто> | <пара> | <список пар><пара>

пара ::= <значение1><значение2> [направление связи] [<число> | <значение3>][условие]

условие ::= <простое условие> | <условие><логическая связка><простое условие> | <условие1><логическая связка><условие2> | (<условие>)

простое условие ::= <пусто> | <атрибут><оператор сравнения><значение>

логическая связка ::= И | ИЛИ | НЕ

оператор сравнения ::= > | < | £ | ³ | ¹ | =

тип связи ::= ‘ресурс’ | ‘документ’ | ‘хранилище’ | <пусто>

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

Составные проекции – проекции (в терминах БИГ), получаемые посредством проекции (в терминах операций реляционной алгебры) на первую и последнюю компоненты соединения двух простых проекций R1 и R2 , по равенству второго столбца проекции R1 и первого столбца проекции R2, домены которых совпадают.

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

Документы (типы документов, что более точно для различения от экземпляров документа) – описания структур данных, определяемых используемыми бумажными документами или иными информационными объектами системы

документ ::= <имя документа><шапка документа><табличная часть документа>

шапка документа ::= <список полей документа 1>

табличная часть документа ::= <список полей документа 2>

список полей документа ::= <поле документа>|<список полей документа><поле документа>

поле документа ::= <тип поля документа ><наименование поля документа>

тип поля документа ::= <символьное>|<числовое, разрядность, точность>|<дата>|<логическое>

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

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

отчет ::= <имя отчета><шапка отчета><табличная часть отчета>

шапка отчета ::= <список полей отчета 1>

табличная часть отчета ::= <список полей отчета 2>

список полей отчета ::= <поле отчета> | <список полей отчет><поле отчета>

поле отчета ::= <тип поля отчета ><наименование поля отчета>

тип поля отчета ::= <символьное> | <числовое, разрядность, точность> | <дата> | <логическое>

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

 

Приложение 2 Формальные средства представления моделей

Как отмечалось в процессе обсуждения функциональных возможностей, каждый из инструментов использует некоторые формальные средства представления и стандарты формализации для построения и/или анализа тех или иных моделей. В настоящем подпункте дается краткая характеристика наиболее известных из таких средств.

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

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

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

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

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

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

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

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

Однако в основе представления всех рассмотренных объектов лежат графы.

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

Но, в отличие от простых однородных графов, для описания указанных S-, I- и D- представлений, необходимо иметь возможность отобразить такие особенности как

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

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

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

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

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

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

В этом отношении ORG-Master имеет неоспоримые преимущества, по сравнению с рассматриваемыми инструментами, в силу единой и простой методологии построения различных моделей (см. Приложение 1. Компоненты моделей программно-методического комплекса ОРГ-Мастер).

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

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

Таблица 3

N п/п

Средство представления

Класс

ARIS

ORG-Master

BP-Win

1
IDEF
Нотация
-
+
+
2
Petri-net (CPN – Color PN)
Математическая модель
+
-
-
3
Yourdon (DFD)
Нотация
-
+
+
4
Object Oriented
Нотация, парадигма программирования

±

-
-
5
UML
Формальный язык
+
-
-
6
ОРГ-Мастер
Математическая модель
-
+
-
7
Martin
Методология проектирования
-
-
-
8
Chen /(ERM) Баркер, Чен
Нотация
+
-
+
9
SSADM
Методология проектирования
-
-
-
10
Gantt
Нотация
-
+
-
11
ABC
Метод оценки
+

±

+
12
Simulation
Метод оценки
+
-
±

 

Обозначения:

- отсутствует
+ Применяется в полной мере
± применяется частично

IDEF: нотация. Насколько разновидностей диаграмм (IDEF0, IDEF1, IDEF1X, IDEF3), предназначенных для:

  • развернутого представления процессов (IDEF0),
  • информационно-концептуального описания структуры объектов и отношений между ними для проектирования баз данных (IDEF1, IDEF1X),
  • представления и анализа протекания процессов (IDEF3).
  • IDEF0 является de facto стандартом описания процессов, рекомендованным к использованию ISO 9000.

Petri Net: математическая модель. Сеть Петри - модель дискретных динамических систем, в том числе информационных. Представляет собой разновидность направленного графа, с двумя типами вершин: местами и переходами, соединенных между собой дугами-связями. Все места имеют первоначальную разметку определенным количеством фишек.

Переходы связывают входное и выходное места и срабатывают при наличии заданного количества фишек во входном месте. Срабатывание переходов перемещает фишки из входных мест в выходные [11, 8, c.262].

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

Yourdon (DFD): нотация. Диаграммы (Data Flow Diagram) функций/процедур, отображающие входные данные и их преобразования в выходные в ходе выполнения процедур, а также взаимосвязь процедур. Цель – (статическое) представление бизнес-процесса.

Компоненты: процессы/функции (зависимая, независимая, ассоциированная),

  • системы/подсистемы,
  • хранилища (неограниченное, ограниченное, существенно-ограниченное),
  • потоки данных,
  • внешние сущности,
  • управляющий процесс, хранилище, поток

Фактически DFD отражает перемещения/преобразования информационных или вещественных объектов [8, с.37]

Object Oriented: нотация, парадигма программирования. Система представляется в виде совокупности взаимодействующих объектов, объединяемых в классы. Объекты обладают свойствами и могут выполнять некоторые действия (методы) – реакции на сообщения, которыми объекты обмениваются друг с другом в процессе взаимодействия.

UML: формальный язык (Unified Modeling Language). Унифицированный язык моделирования, явившийся развитием принципов объектно-ориентированного подхода, (см. Object Oriented). Может использоваться для представления бизнес процессов, структур, деревьев функций событий и пр. и для проектирования информационных систем. Имеет восемь типов диаграмм (вариантов использования, классов, состояний, активностей, последовательностей, кооперации, компонентов развертывания).

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

Язык представляет собой мощное универсальное средство описания моделей различных типов, но достаточно сложен для его применения не профессионалами в области информационных технологий [10].

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

Chen (ERD): нотация. Включает собственно диаграммы ERD (Entity Relation Diagram), а также диаграммы атрибутов (состав/свойства сущности) и диаграммы декомпозиции (категоризации). Ориентирована на проектирование баз данных. Впоследствии модифицирована Баркером, объединившем все три типа диаграмм в диаграммы ERD.

Компоненты:
сущность (зависимая, независимая, ассоциированная),
отношение,
связь сущности и отношения
(типы отношений:

  •  по условиям применимости: неограниченное, ограниченное, существенно-ограниченное,
  • по виду связей 1:1, 1:n, m:n),

(типы связи “0 или 1”, “0/1 или более”, “диапазон” и др.)[8, с.70]

SSADM: Методология разработки информационных систем – 1993 – национальный стандарт Англии (ориентирована на потоки данных).

Функции описываются посредством – DFD (процесс, поток данных, хранилище, внешняя сущность)

Структуры данные представляются на LDS (Logical Data Structure) – диалекте ER-моделей

События представлены диаграммами истории жизни сущностей ELN (Entity Life History), поддерживающими индикаторы состояний, события со связанными действиями, задание последовательных, параллельных и итеративных конструкций и выбора [8, с.130].

Мартин: IE-методология (Information Engineering) разработки информационных систем

(основное внимание – на стратегическое планирование и бизнес-процессы)

Процессы представляются диаграммами декомпозиции (древовидные структурные диаграммы).

Данные описываются диаграммами “сущность-связь”.

Данные с процессами соотносятся матрицами “сущность/процесс” [8, с.135].

Гантт: нотация. Диаграмма, для каждой функции модели процесса – отдельная строка, длина горизонтальной линии указывает продолжительность функции.

Функции могут связываться с ресурсами и организационными звеньями и показывать их загрузку (или расходование – ВВС) [9, с.70].

ABC: метод оценки. Метод (Activity Based Costing) определения ресурсных (временных, материальных, накладных, стоимостных и пр.) затрат на производство продукции и/или услуг на основе операционного анализа процессов их производства, а также вспомогательных процессов. Сводится к сопоставлению ресурсов функциям/процессам, которые, в свою очередь, увязываются с продуктами/услугами.

Simulation: метод оценки параметров. Событийное или имитационное моделирование, используемое для оценки параметров модели бизнес процесса при динамическом его представлении.

 

Приложение 3 Примерное содержание документов «Руководства по качеству», подготавливаемых с помощью  «ОРГ-Мастер»

1.  Общие сведения о системе качества

1.1.  Область действия системы качества

1.1.1.  Виды продукции и услуг

1.1.2.  Отсутствующие элементы системы качества (исключения)

1.2.  Глоссарий, применяемая терминология и сокращения

2.  Политика и цели в области качества.

2.1.  Запросы и ожидания заинтересованных сторон.

(как минимум, идентифицированные Потребности Заказчиков –или ссылка на отдельный документ)

2.2.  Политика в области качества

(Приложение или ссылка на отдельный документ)

2.3.  Цели организации в области качества

(Приложение или ссылка на отдельный документ)

3.  Организация и ответственность.

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

3.1.  Организационно-функциональная структура предприятия

3.1.1.  Организационная диаграмма предприятия

3.1.2.  Положение об организационно-функциональной структуре

3.1.3.  Положения об отдельных видах деятельности

3.1.4.  Положения о подразделениях

3.2.  Должностные инструкции сотрудников

4.  Ресурсное обеспечение и партнеры

(Перечни. Каждый из документов должен быть оформлен в соответствии с внутрифирменным стандартом)

4.1.  Партнеры и внешнее окружение предприятия

4.2.  Основные средства, нематериальные активы, услуги партнеров компании

4.3.  Типы изделий и материалов.

5.  Процессы компании

(Документированные процедуры. Каждый из процессов должен быть оформлен в соответствии с внутрифирменным стандартом)

5.1.  Процессы жизненного цикла продукции.

5.2.  Обеспечивающие процессы

5.3.  Процессы управления

6.  Документальное обеспечение системы качества

6.1.  Применяемая нормативная документация

(Перечень).

6.2.  Хранение и доступ к нормативной документации

(Перечень вида, мест хранения, адресов и способов рассылки нормативной документации )

6.3.  Применяемые записи и отчеты по качеству

(Перечень).

6.4.  Хранение и доступ к записям и отчетам по качеству

(Перечень мест хранения и уровней доступа к записям по качеству)

7.  Развитие и улучшение системы качества

7.1.  Оценка выполнения требований стандарта

(Наличие/отсутствие документированных процедур по каждому из требований стандарта)

7.2.  Оценка «зрелости» процессов организации

(Приложение)

7.3.  План работ по развитию системы качества

(Приложение)

 

Ждем ваших звонков:
+7 (812) 6703162
191015, Россия, Санкт-Петербург,
Фуражный пер., д.3
© 1999-2019 Бизнес Инжиниринг Групп
Написать письмо в службу поддержки сайта Бизнес Инжиниринг Групп
admin@bigc.ru www.bigc.ru  
  Рейтинг@Mail.ru
Главная Новости Контакты Поиск Персональный раздел
© 2006-2007 Разработка сайта - компания Lenvendo Работает на “1С-Битрикс: Управление сайтом”