Виды функций в бизнес моделировании

Содержание

14.1. Контрольные вопросы по функциональному моделированию

1. CASE- средство (Computer-Aided Software Engineering)
2. Деятельность (дело, бизнес)
3. Процесс (бизнеc-процесс)
4. Операция
5. Действие
6. Анализ эффективности бизнес-процессов
7. Декомпозиция бизнес-процесса
8. Критерий оценки эффективности бизнес-процесса
9. Метод OOSE (Object-Oriented Software Engineering)
10. Метод Буча (Booch method)
11. Метод ОМТ (Object Modeling Technique)
12. Моделирование бизнес-процесса
13. Модель «как будет»
14. Модель «как есть»
15. Объект модели
16. Объект создания бизнес-моделей
17. Объектный подход
18. Оптимизация бизнес-процессов
19. Организационное развитие
20. Проверка адекватности модели бизнес-процесса
21. Проект реорганизации бизнес-процессов
22. Реинжиниринг бизнес — процессов (business process reengineering)
23. Реорганизация бизнес-процесса
24. Структурный подход
25. Эффективность бизнес-процесса
26. UML ( Unified Modeling Language )
27. Модель
28. Процессное моделирование
29. Функционально-стоимостной анализ
30. Имитационное моделирование
31. Информационное моделирование
32. Объектно-ориентированное моделирование
33. IDEF 1
34. IDEF1X
35. ERD
36. IDEF2
37. IDEF3
38. IDEF4
39. Блок (Box) в IDEF0
40. Ветвление (Branch) в IDEF0
41. Виды функций в бизнес-моделировании
42. Внутренняя стрелка (Internal Arrow) в IDEF 0
43. Глоссарий (Glossary) в IDEF 0
44. Граничная стрелка (Boundary Arrow) в IDEF 0
45. Декомпозиция (Decomposition) в IDEF0
46. Диаграмма (Diagram) в IDEF 0
47. Диаграмма A-0 в IDEF 0
48. Диаграмма иллюстрация (FEO Diagram) в IDEF 0
49. Доминирование в IDEF 0
50. Дочерний блок (Child Box) в IDEF 0
51. Дочерняя диаграмма (Child Diagram) в IDEF 0
52. Идея IDEF0
53. Имя блока (Box Name) в IDEF 0
54. Классы стрелок в IDEF 0
55. Код-ICOM в IDEF 0
56. Контекст (Context) в IDEF 0
57. Контекстная диаграмма (Context Diagram) в IDEF 0
58. Метка стрелки (Arrow Label) в IDEF 0
59. Модель IDEF0 (IDEF0 Model)
60. Назначение IDEF0
61. Номер блока (Box Number) в IDEF 0
62. Обратная связь по входу в IDEF 0
63. Обратная связь по управлению в IDEF 0
64. Основной принцип IDEF0
65. Основные понятия IDEF0
66. Родительская диаграмма (Parent Diagram) в IDEF 0
67. Родительский блок (Parent Box) в IDEF 0
68. С-номер (C-Number) в IDEF 0
69. Связывание/развязывание (Bundling/Unbundling) в IDEF 0
70. Связь выход-вход в IDEF 0
71. Связь выход-механизм в IDEF 0
72. Связь по управлению в IDEF 0
73. Сегмент стрелки (ветвь) в IDEF 0
74. Слияние (Join) в IDEF 0
75. Стрелка (Arrow) в IDEF 0
76. Стрелка входа (Input Arrow) в IDEF 0
77. Стрелка вызова (Call Arrow) в IDEF 0
78. Стрелка выхода (Output Arrow) в IDEF 0
79. Стрелка механизма ( Mechanism Arrow ) в IDEF 0
80. Стрелка управления (Control Arrow) в IDEF 0
81. Текст (Text) в IDEF 0
82. Тильда (Squiggle) в IDEF 0
83. Типы связей между блоками в IDEF 0
84. Точка зрения (Viewpoint) в IDEF 0
85. Тоннельная стрелка (Tunneled Arrow) в IDEF 0
86. Функция (Activity) в IDEF0
87. Цель (Purpose) в IDEF0
88. Стоимость полнофункциональной версии BPwin (AllFusion Process Modeler 4.1.4) на 1 рабочее место
89. Создатель методологии SADT
90. Основные правила построения диаграмм IDEF0
91. Состав семейства IDEF-методологий
92. Этапы построении функциональной модели
93. IDEF3 (workflow diagramming)
94. Единица работы (Unit of Work) в IDEF3
95. Объект ссылки (Object Referent) в IDEF3
96. Объекты (Objects) в IDEF3
97. Ограничения (Constraints) в IDEF3
98. Перекрестки (Junction) в IDEF3
99. Перекресток разветвления (Fan-out Junction) в IDEF3
100. Перекресток слияния (Fan-in Junction) в IDEF3
101. Связь (Link) в IDEF3
102. Связь объектный поток (Object flow) в IDEF3
103. Связь отношения (Relational) в IDEF3
104. Связь предшествования (Precedence) в IDEF3
105. Факты (Facts) в IDEF3
106. Основные понятия ФСА
107. Принципы связи IDEF0 и ФСА-моделей
108. Диаграммы потоков данных (DFD, Data Flow Diagramming)
109. Внешняя сущность (External Reference) в DFD
110. Поток данных ( Data Flow ) в DFD
111. Процесс в DFD
112. Хранилище данных (Data Store) в DFD

Пред.	Наверх	След.
13.8. Литература	Начало | Содержание	Часть IV. Объектно-ориентированное моделирование

Источник: enisey.name

BPMN.Studio — бесплатный инструмент для моделирования бизнес-процессов

Все виды нотаций для моделирования бизнес-процессов за две минуты

Модель функций

Модель функций представляет собой иерархическую декомпо­зицию функциональной деятельности предприятия. На первом уровне иерархии обычно указываются основные виды функциональных подсистем: сбыт, производство, логистика, сервис, фи­нансы, персонал и т.д. На следующем уровне иерархии для каж­дой функциональной подсистемы показываются функциональные модули, например подсистема «Логистика» включает в себя фун­кциональные модули: планирование потребности в материалах, закупки, управление запасами, управление складами, проверка платежей и т.д. для функциональных модулей задаются наборы бизнес-функций, для каждой из которых в дальнейшем определя­ются бизнес-процессы. Например, для функционального модуля «закупки» определяются бизнес-функции: оформление договоров, оформление заказов, выписка счетов и т .д.

Базовая модель

Объекты Орг.структура Функции Процессы Правила Типовая модель:

Модель Предприятия

Объекты Функции Процессы Организац. структура Типовая модель:

Типовая модель:

Объекты Функции Процессы Орг.струк-тура Конфигурация Информационной системы Рис.2. Конфигурация ИС на основе модельно-ориентированной технологии В системе R/3 просмотр функциональности типовой ИС осу­ществляется с помощью программы-навигатора репозитория.

Пример навигации на фрагменте модели функций показан на рис.3. в процессе навигации по дереву можно перейти к докумен­тации, описывающей соответствующую функцию, и определению подфункций. Рис.3. Фрагмент модели функций в системе R/3 В системе BAANIV cпомощью инструментаEnterpriseModelerможно построить четырехуровневое дерево декомпозиции функций (рис.4.) В отличие отR/3 бизнес-функции могут называться именами, которые характерны для конкретного предприятия. Кроме того, для функций могут быть заданы показатели эффективности их выполнения, произвольное текстовое описание (например: инструкции для выполнения), а для последнего уровня указываются варианты реализации (оптимизации) по мере внедрения ИС.

Рис. 4. Модель функций системы BAAN IV

Модель процессов

Модель бизнес-процесса отражает последовательность вы­полнения работ (операций) для функций самого нижнего уровня модели бизнес-функций, которая позволяет провести конфигу­рацию программных модулей информационной системы в соот­ветствии с характерными особенностями конкретной проблем­ной области. Как в системе R/З, так и в системе BAAN IV для представле­ния бизнес-процессов используется аппарат сетей Петри, позво­ляющий отображать управление процессами в зависимости от событий: работа выполняется в том случае, если на входе извест­но состояние системы.

В системе R/З для отображения процессов используется мо­дель управления событиями (ЕРС -event-driven process chain), реализованная в ARIS Toolset (рис.5). В соответствии с этим методом переходы между операциями осуществляются в зависи­мости от событий, которые могут связываться логическими связ­ками AND, OR, XOR.

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

Модель бизнес-процесса, построенная с помощью BAAN Enterprise Modeler (рис.6), позволяет в качестве операций ис­пользовать не только программные модули BAAN IV, но и руч­ные процедуры, приложения, разработанные в другой программ­ной среде. Конкретные операции могут иметь вложенные набо­ры операций, т.е. представляться в виде подпроцессов.

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

Модель управления событиями бизнес-процесса в системе R/3 Рис.6. Модель бизнес-процесса в среде BAAN Enterprise Modeler Модели объектов (данных) В модельно-ориентированной технологии проектирования ИС интегрирование различных бизнес-процессов (приложений) осуществляется на основе бизнес-объектов.

Согласно определению комитета Business Object Task Force OMGбизнес-объекты -компоненты уровня проблемной области, которые исполь­зуются в различных приложениях в произвольных комбинациях и не зависят от них. При этом «приложение обеспечивает среду для функционирования бизнес-объектов».OMGразрабатывает спецификации программных оболочек, которые предоставляют готовые объекты для приложений: производства, элек­тронной коммерции, транспортировки, телекоммуникаций, здра­воохранения, финансов и др.

С одной стороны, бизнес-объекты — это объекты-сущности в нотации UML, например заказы, счета, материалы, поставщики и т.д. С другой стороны, в отличие от обычных объектов-сущностей бизнес-объекты являются самодостаточными, т.е. имеют стандартный интерфейс, написанный на языке описания интерфейсов IDL (Interface Dermition Language), с помощью ко­торого бизнес-объекты могут взаимодействовать друг с другом через объектную шину — брокер объектных запросов (Object Request Broker).

Таким образом, бизнес-объекты обладают бо­лее сложной внутренней структурой по сравнению с простыми объектами. Например, структура бизнес-объектов R/3 включает ограничения целостности в виде допустимых типов связей с дру­гими объектами и бизнес-правила по связям с внешней средой, интерфейсы в виде входных-выходных событий и спецификации доступа к объектам.

В системе R/3 разработано более 100 стандартных интерфей­сов бизнес-объектов, называемых BAPI (Business Application Programming Interface), которые позволяют осуществлять непос­редственную связь между приложениями разных предприятий в среде ИНТЕРНЕТ. Например, при оформлении заказа от клиен­та поставщику могут использоваться следующие стандартные ме­тоды бизнес-объектов: ProductGroup.Select- выбор группы изделий в каталоге; Product.Description- просмотр описания изделия; Product.Select- выбор изделия из группы; Order.Create- создание заказа и т.д.

В системе R/3 модель бизнес-объектов описывается как ста­тическая ER-модeль, в которой каждая сущность может рассмат­риваться как обычный объект данных, который используется на входе или выходе операций, так и как бизнес-объект с присоеди­ненными методами. В инструменте BAAN Enterprise Modeler модель бизнес-объек­тов не отражается вследствие использования стандартной струк­туры базы данных, которую можно настраивать на особенности конкретного предприятия.

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

С помощью инструмента BEW в модели бизнес-процесса явно указывается закрепление автоматизированных функций по под­разделениям (см. рис.5). С помощью инструмента Enterprise Mode1er связь модели бизнес-процесса и модели организационной структуры задается через указатели роли, которые могут выполняться различными организационными единицами (рис.7).

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

При назначении работы конкретному ра­ботнику всегда осуществляется проверка роли, которую он может выполнять. Если при этом тип конкретного работника не соот­ветствует роли, то последний не получает доступа к выполнению работы. Рис.7. Установление связи модели организационной структуры и модели бизнес-процесса

Источник: studfile.net

Функциональная модель (Function Tree — FT).

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

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

Пример функциональной модели приведен на рис. 6.2.

Рис. 6.2. Модель описания бизнес-процессов верхнего уровня

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

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

Процессно-событийная модель (Extended Event-Driven Process Chain — еЕРС)

Процессно-событийная модель (Extended Event-Driven Process Chain — еЕРС) (кратко — модель или диаграмма еЕРС) предназначена для детального описания процессов, выполняемых в рамках одного подразделения, несколькими подразделениями или конкретными сотрудниками.

Графические элементы функциональной модели

Представление в ARIS Express

Наименование, описание, пример

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

Цвет фигуры, зеленый.

Пример, выдача заказа клиенту, формирование приказа на стипендию, заселение в общежитие и т.п.

Модель еЕРС позволяет выявлять взаимосвязи между организационной и функциональной моделями.

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

Нотации ARIS еЕРС и IDEF3 базируются на одних и тех же принципах моделирования потоков работ (Work Flow), предполагающих использование символов логики («перекрестков» в 1DEF3). С помощью этих символов отражаются ветвления и слияния потоков работ в рамках бизнес-процесса.

Модель еЕРС является расширением методологии IDEF3 за счет такого понятия, как событие (Event). Возможность моделирования событий в ARIS еЕРС позволяет создавать более корректные и подробные описания процессов. При этом, однако, существенно повышается сложность и трудоемкость описания.

Модель еЕРС наиболее информативна и удобна при описании деятельности подразделений организации.

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

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

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

Основу модели составляют чередующиеся объекты функция (Function) и событие (Event), связанные друг с другом. Пример простой цепочки (без ветвлений) событий и функций приведен на рис. 6.3.

Рис. 6.3. Цепочка событий и функций

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

• • наступление плановой даты, времени, например, «принято решение о начале проекта»;
• • получение или отправка работником заявки, распоряжения, формы, информации, например, «поступила заявка от клиента».

Для удобства восприятия создаваемых моделей необходимо придерживаться ряда правил графического расположения объектов:

• 1. События и функции принято располагать последовательно сверху вниз.
• 2. Объекты, составляющие окружение функций (документы, данные, организационные элементы и информационные системы), располагаются относительно функции следующим образом:

• • входящие документы и данные — слева сверху;
• • исходящие документы и данные — слева снизу;
• • исполнители (организационные элементы) — справа но центру.

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

Рис. 6.4. Цепочка событий и функций и интерфейсов в другие процессы

Модель еЕРС выстраивается в соответствии со следующими правилами:

• 1. Каждая модель еЕРС должна начинаться как минимум одним стартовым инициирующим событием и завершаться как минимум одним результирующим событием.
• 2. События и функции должны иметь только по одному входящему и исходящему отношению (связи), показывающему ход управления процесса.
• 3. Путь процесса всегда разделяется и объединяется с помощью правил ветвления/слияния (об этом будет информация далее по тексту).

Для описания ветвлений процесса используется объект «Оператор правила» (Rule Operator), который размещается между функциями и событиями и соединяется с ними таким образом, чтобы правило имело одну входящую связь и несколько исходящих связей либо несколько входящих связей и одну исходящую связь, как это представлено в примерах на рис. 6.5.

Рис. 6.5. Варианты использования операторов правила

Принципы использования правил на модели типа еЕРС приведены в табл. 6.4.

Типы ветвления и соединения процесса на модели типа еЕРС

(«исключающее “или»»)

Функция выполняется, если наступили все события

Функция начинает выполняться тогда, когда наступает только одно из событий

Функция начинает выполняться, если хотя бы одно из событий наступает

После выполнения функции наступают все события

После выполнения функции наступает ровно одно из событий

После выполнения функции наступает хотя бы одно из событий

Событие наступает, когда выполнены обе функции

Событие наступает после выполнения ровно одной функции

Событие наступает после выполнения хотя бы одной функции

Окончание табл. 6.4

Примеры модели типа еЕРС приведены на рис. 6.6.

Рис. 6.6. Модель процесса типа еЕРС

Рис. 6.6. Окончание

В табл. 6.5 приведен список объектов модели процессов, а в табл. 6.6 список допустимых взаимосвязей между объектами модели.

Объекты модели процесса

Представление в ARIS Express

Наименование, описание, пример

Событие, объект, описывающий событие.

Цвет фигуры, оранжевый.

Пример, начат прием документов абитуриентов на обучение в вуз, завершился учебный год, истек срок хранения документов в архиве

Функция, одна или несколько, выполнение которой направлено на достижение результата.

Цвет фигуры, зеленый.

Пример, выдача заказа клиенту, формирование приказа на стипендию, заселение в общежитие и т.п.

Должность, элементарная организационная единица компании. Под должностью следует понимать штатную единицу, занимаемую конкретным сотрудником.

В модели указывается наименование должности.

Окончание табл. 6.5

Представление в ARIS Express

Наименование, описание, пример

Цвет фигуры, желтый.

Примеры, диспетчер факультета «Информационные системы и технологии», инженер 1-й категории, ведущий специалист отдела кадров

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

Цвет фигуры, серый

Информационные носители как материальной формы («бумажные» документы), так и электронного представления информации.

базы данных, файлы, электронные письма, интернет-ресурсы и т.д.

Цвет фигуры, серый.

Пример, личная карточка учащегося, база данных учащихся

Ґ Process К interface

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

Типы связей между элементами модели еЕРС

Типы связей между элементами

Источник: studme.org