Лекция 8. Методологии DFD и IDEF3
Для того чтобы документировать механизмы передачи и обработки информации в моделируемой системе, используются диаграммы потоков данных (Data Flow Diagrams). Диаграммы DFD обычно строятся для наглядного изображения текущей работы системы документооборота вашей организации. Чаще всего диаграммы DFD используют в качестве дополнения модели бизнес-процессов, выполненной в IDEF0.
Всего DFD использует четыре важных элемента:
В отличие от стрелок IDEF0, которые представляют собой жесткие взаимосвязи, стрелки DFD показывают, как объекты (включая данные) двигаются от одной работы к другой.
Стрелки (Потоки данных). Стрелки описывают движение объектов из одной части системы в другую. Поскольку в DFD каждая сторона работы не имеет четкого назначения, как в IDEF0, стрелки могут подходить и выходить из любой грани прямоугольника работы. В DFD также применяются двунаправленные стрелки для описания диалогов типа "команда-ответ" между работами, между работой и внешней сущностью и между внешними сущностями (рис. 8.1).
Рисунок 8.1 - Внешняя сущность
Хранилище данных. В отличие от стрелок, описывающих объекты в движении, хранилища данных изображают объекты в покое (рис. 8.2).
Рисунок 8.2 - Хранилище данных
В материальных системах хранилища данных изображаются там, где объекты ожидают обработки, например в очереди. В системах обработки информации хранилища данных являются механизмом, который позволяет сохранить данные для последующих процессов.
Рисунок 8.3 - Пример диаграммы DFD
В диаграммах потоков данных все используемые символы складываются в общую картину, которая дает четкое представление о том, какие данные используются, и какие функции выполняются системой документооборота. При этом часто выясняется, что существующие потоки информации, важные для деятельности компании, реализованы ненадежно и нуждаются в реорганизации.
Наличие в диаграммах DFD элементов для описания источников, приемников и хранилищ данных позволяет точно описать процесс документооборота. Однако для описания логики взаимодействия информационных потоков модель дополняют диаграммами еще одной методологии - IDEF3, также называемой workflow diagramming. Методология моделирования IDEF3 позволяет графически описать и задокументировать процессы, фокусируя внимание на течении этих процессов и на отношениях процессов и важных объектов, являющихся частями этих процессов.
IDEF3 предполагает построение двух типов моделей: модель может отражать некоторые процессы в их логической последовательности, позволяя увидеть, как функционирует организация, или же модель может показывать “сеть переходных состояний объекта”, предлагая вниманию аналитика последовательность состояний, в которых может оказаться объект при прохождении через определенный процесс.
С помощью диаграмм IDEF3 можно анализировать сценарии из реальной жизни, например, как закрывать магазин в экстренных случаях или какие действия должны выполнить менеджер и продавец при закрытии. Каждый такой сценарий содержит в себе описание процесса и может быть использован, что бы наглядно показать или лучше задокументировать бизнес-функции организации.
Модель, выполненная в IDEF3, может содержать следующие элементы:
o Перекресток ветвления (Fan-out Junction) - узел, в котором единственная входящая в него стрелка ветвится, показывая, что работы, следующие за перекрестком, выполняются параллельно или альтернативно.
Таблица 1.4. Типы перекрестков
Обозначение | Наименование | Смысл в случае слияния стрелок (Fan-in Junction) | Смысл в случае разветвления стрелок (Fan-out Junction) |
Asynchronous AND | Все предшествующие процессы должны быть завершены | Все следующие процессы должны быть запущены | |
Synchronous AND | Все предшествующие процессы завершены одновременно | Все следующие процессы запускаются одновременно | |
Asynchronous OR | Один или несколько предшествующих процессов должны быть завершены | Один или несколько следующих процессов должны быть запущены | |
Synchronous OR | Один или несколько предшествующих процессов завершены одновременно | Один или несколько следующих процессов запускаются одновременно | |
XOR (Exclusive OR) | Только один предшествующий процесс завершен | Только один следующий процесс запускается |
Всё перекрестки на диаграмме нумеруются, каждый номер имеет префикс J. Можно редактировать свойства перекрестка при помощи диалога Definition Editor. В отличие от IDEF0 и DFD в IDEF3 стрелки могут сливаться и разветвляться только через перекрестки.
· Объекты ссылок (Referents) - служат для выражения идей и концепций без использования специальных методов, таких как стрелки, перекрестки или работы. Объект ссылки изображается в виде прямоугольника, похожего на прямоугольник работы. Имя объекта ссылки задается в диалоге Referent (пункт всплывающего меню Name Editor), в качестве имени можно использовать имя какой-либо стрелки с других диаграмм или имя сущности из модели данных. Объекты ссылки должны быть связаны с единицами работ или перекрестками пунктирными линиями. Официальная спецификация IDEF3 различает три стиля объектов ссылок - безусловные (unconditional), синхронные (synchronous) и асинхронные (asynchronous). BPwin поддерживает только безусловные объекты ссылок. Синхронные и асинхронные объекты ссылок, используемые в диаграммах переходов состояний объектов, не поддерживаются.
Декомпозиция работ. В IDEF3 декомпозиция используется для детализации работ. Методология IDEF3 позволяет декомпозировать работу многократно, т.е. работа может иметь множество дочерних работ. Это позволяет в одной модели описать альтернативные потоки. Возможность множественной декомпозиции предъявляет дополнительные требования к нумерации работ. Так, номер работы состоит из номера родительской работы, версии декомпозиции и собственного номера работы на текущей диаграмме (рис. 1.54).
Рисунок 8.5 - Номер единицы работы (UOW)
Рисунок 8.6 Пример диаграммы IDEF3
Рассмотрим процесс декомпозиции диаграмм IDEF3, включающий взаимодействие автора (аналитика) и одного или нескольких экспертов предметной области.
Кроме того, что уже было сказано по поводу трех поддерживаемых BPwin методологий, необходимо отметить еще несколько вещей. Как мы уже замечали ранее модель, выполненная в BPwin представляет собой набор иерархически упорядоченных диаграмм (не обязательно сделанных в одной методологии, чаще модели бывают смешанными). При размещении на очередной диаграмме некоторого элемента (работы, стрелки…) этот элемент вместе со всеми своими свойствами (которые всегда можно просмотреть или изменить в соответствующем редакторе BPwin) автоматически заносится в словарь BPwin, в результате вместе с графическим изображением моделируемой системы аналитик получает десятки страниц с подробным текстовым описанием системы.
Применение универсальных графических языков бизнес-моделирования IDEF0, IDEF3 и DFD обеспечивает логическую целостность и полноту описания, необходимую для достижения точных и непротиворечивых результатов. Посредством набора графических инструментов для отображения действий и объектов, BPwin позволяет легко построить схему процесса, на которой показаны исходные данные, результаты операций, ресурсы, необходимые для их выполнения, управляющие воздействия, взаимные связи между отдельными работами. Интерактивное выделение объектов обеспечивает постоянную визуальную обратную связь при построении модели. BРwin поддерживает ссылочную целостность, не допуская определения некорректных связей и гарантируя непротиворечивость отношений между объектами при моделировании.
& Наличие в диаграммах DFD элементов для описания источников, приемников и хранилищ данных позволяет более эффективно и наглядно описать процесс документооборота.
Однако дляописания логики взаимодействия информационных потоков более подходит IDEF3 , называемая также workflow diagramming - методологией моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов.
Диаграммы Workflow могут быть использованы в моделировании бизнес-процессов для анализа завершенности процедур обработки информации. С их помощью можно описывать сценарии действий сотрудников организации, например последовательность обработки заказа или события, которые необходимо обработать за конечное время. Каждый сценарий сопровождается описанием процесса и может быть использован для документирования каждой функции.
IDEF3 - это метод, имеющий основной целью дать возможность аналитикам описать ситуацию, когда процессы выполняются в определенной последовательности, а также описать объекты, участвующие совместно в одном процессе .
Каждая работа в IDEF3 описывает какой-либо сценарий бизнес-процесса и может являться составляющей другой работы. Поскольку сценарий описывает цель и рамки модели, важно, чтобы работы именовались отглагольным существительным, обозначающим процесс действия, или именным словосочетанием, содержащим такое существительное.
Точка зрения на модель должна быть задокументирована. Обычно это точка зрения человека, ответственного за работу в целом. Также необходимо задокументировать цель модели - те вопросы, на которые призвана ответить модель.
Диаграмма является основной единицей описания в IDEF3 Важно правильно построить диаграммы, поскольку они предназначены для чтения другими людьми (а не только автором).
Единицы работы – Unit of Work (UOW) , также называемые работами (activity), являются центральными компонентами модели. В IDEF3 работы изображаются прямоугольниками с прямыми углами (рис. 6.1.) и имеют имя , выраженное отглагольным существительным, обозначающим процесс действия , одиночным или в составе словосочетания, и номер (идентификатор); другое имя существительное в составе того же словосочетания, зависимое от отглагольного существительного, обычно отображает основной выход (результат) работы (например, "Изготовление изделия"}.
Рис. 6.1. Обозначение работы в диаграмме IDEF3
Связи показывают взаимоотношения работ. Все связи в IDEF3 однонаправлены и могут быть направлены куда угодно, но обычно диаграммы IDEF3 стараются построить так, чтобы связи были направлены слева направо . В IDEF3 различают три типа стрелок, изображающих связи, стиль которых устанавливается во вкладке Style (рис. 6.2.) диалога Arrow Properties (пункт контекстного меню Style ).
Рис. 6.2. Вкладка Style диалога Arrow Properties
Старшая (Precedence) стрелка - сплошная линия, связывающая единицы работ (UOW). Рисуется слева направо или сверху вниз. Показывает, что работа-источник должна закончиться прежде, чем работа-цель начнется.
Стрелка отношения (Relational) - пунктирная линия, использующаяся для изображения связей между единицами работ (UOW), а также между единицами работ и объектами ссылок.
Потоки объектов (Object Flow) - стрелка с двумя наконечниками, применяется для описания того факта, что объект используется в двух или более единицах работы, например, когда объект порождается в одной работе и используется в другой.
Старшая связь показывает, что работа-источник заканчивается ранее, чем начинается работа-цель. Часто результатом работы-источника становится объект, необходимый для запуска работы-цели. В этом случае стрелку, обозначающую объект, изображают с двойным наконечником. Имя стрелки должно ясно идентифицировать отображаемый объект. Поток объектов имеет ту же семантику, что и старшая стрелка.
Отношение показывает, что стрелка является альтернативой старшей стрелке или потоку объектов в смысле задания последовательности выполнения работ - работа-источник не обязательно должна закончиться прежде, чем работа-цель начнется. Более того, работа-цель может закончиться прежде, чем закончится работа-источник (рис. 6.3.).
Рис. 6.3. Временная диаграмма выполнения работ
Перекрестки (Junction). Окончание одной работы может служить сигналом к началу нескольких работ, или же одна работа для своего запуска может ожидать окончания нескольких работ. Перекрестки используются для отображения логики взаимодействия стрелок при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы.
Различают перекрестки для слияния (Fan-in Junction ) и разветвления (Fan-in Junction ) стрелок. Перекресток не может использоваться одновременно для слияния и разветвления.
Для внесения перекрестка служит кнопка в палитре инструментов. В диалоге Junction Туре Editor нужно будет указать тип перекрестка (рис. 6.4.).
Рис. 6.4. Типы перекрестков
Смысл каждого типа приведен в таблице 6.1.
Таблица 6.1. Типы перекрестков
Обозначение | Наименование | Смысл в случае слияния стрелок Fan-in Junction | Смысл в случае разветвления стрелок Fan-in Junction |
Асинхронное «И» (Asynchronous AND) | Все предшествующие процессы должны быть завершены | Все следующие процессы должны быть запущены | |
Синхронное «И» (Synchronous AND) | Все предшествующие процессы завершены одновременно | Все следующие процессы запускаются одновременно | |
Асинхронное «ИЛИ» (Asynchronous OR) | Один или несколько предшествующих процессов должны быть завершены | Один или несколько следующих процессов должны быть запущены | |
Синхронное «ИЛИ» (Synchronous OR) | Один или несколько предшествующих процессов завершены одновременно | Один или несколько следующих процессов запускаются одновременно | |
Исключающее «ИЛИ» XOR (Exclusive OR) | Только один предшествующий процесс завершен | Только один следующий процесс запускается |
Все перекрестки на диаграмме нумеруются, каждый номер имеет префикс J (рис. 6.5.).
Формат IDEF3 применяется для описания бизнес-процессов в виде потоков операций (работ). Условные обозначения формата IDEF3 представлены в следующих таблицах 4 и 5.
Операции (работы) обозначают преобразования потоков материальных, финансовых ресурсов и информации (документов, файлов). Операции изображаются прямоугольниками со сплошными границами и прямыми углами, при этом нижняя часть прямоугольника отделена сплошной линией.
Каждая операция имеет название и номер. Название операции выражается глаголом или отглагольным существительным. Номер операции используется для ее идентификации в модели. Стрелки связей обозначают взаимосвязи между выполняемыми операциями, которые могут выражаться через связь операций посредством потока объектов или последовательность выполнения операций во времени.
Связь между операциями, выраженная как последовательность выполнения во времени может быть двух видов: 1) старшая связь; 2) связь-отношение.
Рис.5. - Контекстная диаграмма процесса подготовки документа в нотации IDEF0
Рис.6. - Диаграмма процесса подготовки документа в нотации IDEF0
Таблица 4. - Условное обозначение связей и потоков в IDEF3 диаграммах
Таблица 5. - Условные обозначения и описание элементов формата IDEF3
Старшая связь показывает, что для начала работы одной операции необходимо завершение выполнения другой. Старшая связь изображается однонаправленной сплошной стрелкой с одним наконечником.
Связь-отношение показывает, что для выполнения операции нет необходимости в завершении выполнения другой операции. необходимо только начать выполнение этой операции. Связь-отношение изображается однонаправленной пунктирной стрелкой с одним наконечником.
Стрелки изображаются вертикальными и горизонтальными отрезками прямых с одним или двумя наконечниками конце, пересекающиеся под прямым углом и сопряженные дугами. Стрелки соединяются с прямоугольниками, изображающими операции следующим образом:
1) концы стрелок должны касаться внешней стороны прямоугольника, но не пересекать ее;
2) стрелки должны подсоединяться к прямоугольнику на его сторонах, присоединение в углах не допускается;
3) в отличие от IDEF0-диаграмм, стрелки могут подходить и исходить из любых граней прямоугольников.
Объект модели типа «перекресток» используется для отображения логики взаимодействия стрелок при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом выполнения следующей операции. Перекрестки используются для обозначения следующих ситуаций: окончание реализации одной операции может служить сигналом к началу выполнения нескольких операций, или же одна операция для своего запуска может ожидать окончания выполнения нескольких операций. Стрелки могут сливаться и разветвляться только через перекрестки. В таблице 6 приводятся типы используемых перекрестков.
Таблица 6. - Описание типов перекрестков EDF3 диаграмм
Перекресток изображается квадратом, с двойной правой или левой границей. Правила создания перекрестков:
1) участия важного объекта в выполнении операции;
2) циклов выполнения операций;
3) частоты выполнения операций;
При построении диаграмм в IDEF3 используется принцип декомпозиции. В результате декомпозиции образуется иерархическая структура диаграмм IDEF3.
Родительская диаграмма, расположенная на вершине иерархической структуры диаграмм, должна быть либо диаграммой IDEF0, либо диаграммой DFD. В случае, если IDEF3 диаграммы не дополняют IDEF0 модель или DFD модель, а являются самостоятельной моделью, то на указанной родительской диаграмме верхнего уровня должна быть обозначена цель моделирования и точка зрения создателя модели.
Правила построения диаграмм IDEF3 включают:
Примеры диаграмм процесса в нотации IDEF3 представлены на Рис.7- Рис. 10:
Рис. 7. - Диаграмма IDEF3 процесса сбора и проверки информации
Рис. 8. - Диаграмма IDEF3 процесса обработки полученной информации
Рис. 9. - Диаграмма IDEF3 процесса анализа проекта документа
Рис. 10. - Диаграмма IDEF3 процесса согласования и утверждения документа
С помощью этой практической работы Вы сможете:
освоить принципы построения диаграммы IDEF3;
научиться устанавливать связи между работами;
освоить правила создания перекрестков.
Теоретические сведения
& Наличие в диаграммахDFDэлементов для описания источников, приемников и хранилищ данных позволяет более эффективно и наглядно описать процесс документооборота.
Однако дляописания логики взаимодействия информационных потоков более подходитIDEF 3 , называемая такжеworkflow diagramming -методологией моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов.
Диаграммы Workflow могут быть использованы в моделировании бизнес-процессов для анализа завершенности процедур обработки информации. С их помощью можно описывать сценарии действий сотрудников организации, например последовательность обработки заказа или события, которые необходимо обработать за конечное время. Каждый сценарий сопровождается описанием процесса и может быть использован для документирования каждой функции.
IDEF 3 - это метод, имеющий основной целью дать возможность аналитикамописать ситуацию, когда процессы выполняются в определенной последовательности, а также описать объекты, участвующие совместно в одном процессе .
Каждая работа в IDEF 3 описывает какой-либо сценарий бизнес-процесса и может являться составляющей другой работы. Поскольку сценарий описывает цель и рамки модели, важно, чтобы работы именовались отглагольным существительным, обозначающим процесс действия, или именным словосочетанием, содержащим такое существительное.
Точка зрения на модель должна быть задокументирована. Обычно это точка зрения человека, ответственного за работу в целом. Также необходимо задокументировать цель модели - те вопросы, на которые призвана ответить модель.
Диаграмма является основной единицей описания вIDEF 3 Важно правильно построить диаграммы, поскольку они предназначены для чтения другими людьми (а не только автором).
Единицы работы – Unit of Work (UOW ) , также называемые работами (activity), являются центральными компонентами модели. ВIDEF 3 работы изображаютсяпрямоугольниками с прямыми углами (рис. 6.1.) и имеютимя , выраженное отглагольным существительным,обозначающим процесс действия , одиночным или в составе словосочетания, иномер (идентификатор); другое имя существительное в составе того же словосочетания, зависимое от отглагольного существительного, обычно отображает основной выход (результат) работы (например, "Изготовление изделия"}.
Рис. 6.1. Обозначение работы в диаграмме IDEF 3
Связи показывают взаимоотношения работ. Все связи вIDEF 3 однонаправлены и могут быть направлены куда угодно, но обычно диаграммыIDEF3 стараются построить так, чтобысвязи были направлены слева направо . ВIDEF3 различают три типа стрелок, изображающих связи, стиль которых устанавливается во вкладкеStyle (рис. 6.2.) диалогаArrow Properties (пункт контекстного менюStyle ).
Рис. 6.2. Вкладка Style диалога Arrow Properties
Старшая (Precedence) стрелка - сплошная линия, связывающая единицы работ (UOW). Рисуется слева направо или сверху вниз. Показывает, что работа-источник должна закончиться прежде, чем работа-цель начнется.
Стрелка отношения (Relational) - пунктирная линия, использующаяся для изображения связей между единицами работ (UOW), а также между единицами работ и объектами ссылок.
Потоки объектов (ObjectFlow)- стрелка с двумя наконечниками, применяется для описания того факта, что объект используется в двух или более единицах работы, например, когда объект порождается в одной работе и используется в другой.
Старшая связь показывает, что работа-источник заканчивается ранее, чем начинается работа-цель. Часто результатом работы-источника становится объект, необходимый для запуска работы-цели. В этом случае стрелку, обозначающую объект, изображают с двойным наконечником. Имя стрелки должно ясно идентифицировать отображаемый объект. Поток объектов имеет ту же семантику, что и старшая стрелка.
Отношение показывает, что стрелка является альтернативой старшей стрелке или потоку объектов в смысле задания последовательности выполнения работ - работа-источник не обязательно должна закончиться прежде, чем работа-цель начнется. Более того, работа-цель может закончиться прежде, чем закончится работа-источник (рис. 6.3.).
Рис. 6.3. Временная диаграмма выполнения работ
Перекрестки (Junction ). Окончание одной работы может служить сигналом к началу нескольких работ, или же одна работа для своего запуска может ожидать окончания нескольких работ. Перекрестки используются для отображения логики взаимодействия стрелок при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы.
Различают перекрестки для слияния (Fan - in Junction ) и разветвления (Fan - in Junction ) стрелок. Перекресток не может использоваться одновременно для слияния и разветвления.
Для внесения перекрестка служит кнопка в палитре инструментов. В диалогеJunction Туре Editor нужно будет указать тип перекрестка (рис. 6.4.).
Рис. 6.4. Типы перекрестков
Смысл каждого типа приведен в таблице 6.1.
Таблица 6.1. Типы перекрестков
Обозначение |
Наименование |
Смысл в случае слияния стрелок Fan - in Junction |
Смысл в случае разветвления стрелок Fan - in Junction |
Асинхронное «И» (Asynchronous AND) |
Все предшествующие процессы должны быть завершены |
Все следующие процессы должны быть запущены |
|
Синхронное «И» (Synchronous AND) |
Все предшествующие процессы завершены одновременно |
Все следующие процессы запускаются одновременно |
|
Асинхронное «ИЛИ» (Asynchronous OR) |
Один или несколько предшествующих процессов должны быть завершены |
Один или несколько следующих процессов должны быть запущены |
|
Синхронное «ИЛИ» (Synchronous OR) |
Один или несколько предшествующих процессов завершены одновременно |
Один или несколько следующих процессов запускаются одновременно |
|
Исключающее «ИЛИ» XOR |
Только один предшествующий процесс завершен |
Только один следующий процесс запускается |
Все перекрестки на диаграмме нумеруются, каждый номер имеет префикс J (рис. 6.5.).
Рис. 6.5. Обозначение нумерации перекрестка
Можно редактировать свойства перекрестка (рис 6.6.) при помощи диалога Junction Properties , который вызывается из контекстного меню.
Рис. 6.6. Диалоговое окно свойств перекрестков
В отличие от IDEF 0 и DFD в IDEF 3 стрелки могут сливаться и разветвляться только через перекрестки.
Правила создания перекрестков. На одной диаграммеIDEF3 может быть создано несколько перекрестков различных типов. Определенные сочетания перекрестков для слияния и разветвления могут приводить к логическим несоответствиям. Чтобы избежать конфликтов, необходимо соблюдать следующие правила:
Каждому перекрестку для слияния должен предшествовать перекресток для разветвления.
синхронного илиасинхронного «ИЛИ». Действительно, после работы 1 может запускаться только одна работа - 2 или 3, а для запуска работы 4 требуется окончание обеих работ - 2 и 3. Такой сценарий не может реализоваться (рис. 6.7.).
Рис. 6.7. Неверное размещение перекрестков. Перекресток для слияния «И» не может следовать за перекрестком для разветвления «ИЛИ»
Перекресток для слияния «И» не может следовать за перекрестком для разветвления типа исключающего «ИЛИ» (рис. 6.8.).
Рис. 6.8. Неверное размещение перекрестков. Перекресток для слияния «И» не может следовать за перекрестком для разветвления типа исключающего «ИЛИ»
Перекресток для слияния типа исключающего «ИЛИ» не может следовать за перекрестком для разветвления типа «И» (рис. 6.9.). Здесь после завершения работы 1 запускаются обе работы - 2 и 3, а для запуска работы 4 требуется, чтобы завершилась одна и только одна работа - или 2, или 3.
Рис. 6.9. Неверное размещение перекрестков. Перекресток для слияния типа исключающего «ИЛИ» не может следовать за перекрестком для разветвления типа «И»
Перекресток, имеющий одну стрелку на одной стороне, должен иметь более одной стрелки на другой.
Практическое задание « Создание диаграммы IDEF 3 »
Построение модели рассмотрим на примере бизнес-процесса "Сборка изделия".
Упражнение 3 2 . Создание диаграммы IDEF3 .
Рис. 6.10. Выбор нотации IDEF 3 в диалоге Activity Box Count
Возникает диаграмма IDEF 3 , содержащая работы (UOW ).
Правой кнопкой мыши щелкните по работе, выберите в контекстном меню Name и внесите имя работы «Подготовка компонентов».
Во вкладке Definition внесите определение «Подготавливаются все компоненты корпусной мебели согласно спецификации заказа» (рис. 6.11.).
Рис. 6.11. Диалоговое окно свойств работы
Во вкладку UOW , внесите свойства работы (таблица 6.2.).
Таблица 6.2. СвойстваUOW
Тип |
Использование |
Подготовка деталей изделия |
|
Подготавливаются все детали изделия согласно спецификации заказа |
Стандарт IDEF0 является развитием классического DFD - подхода и предназначен для описания бизнес-процессов верхнего уровня. Для описания временной последовательности и алгоритмов выполнения работ стандарт IDEF0 не подходит. Для решения этой задачи стандарт IDEF0 получил дальнейшее развитие в результате чего был разработан стандарт IDEF3, который входит в семейство стандартов IDEF.
В IDEF3 декомпозиция используется для детализации работ. Методология IDEF3 позволяет декомпозировать работу многократно, т.е. работа может иметь множество дочерних работ. Это позволяет в одной модели описать альтернативные потоки. Возможность множественной декомпозиции предъявляет дополнительные требования к нумерации работ. Так, номер работы состоит из номера родительской работы, версии декомпозиции и собственного номера работы на текущей диаграмме.
Отличием стандарта IDEF3 от классической методологии WFD является также использование на схеме бизнес-процесса элемента «объект ссылки», который связывается с работами и перекрестками. С помощью объектов ссылки показывается прочая важная информация, которую целесообразно зафиксировать при описании бизнес-процесса.
IDEF3 предполагает построение двух типов моделей: 1) модель, отражающая некоторые процессы в их логической последовательности, позволяющая увидеть, как функционирует предприятие;
2) модель, показывающая «сеть переходных состояний объекта», предлагающая вниманию аналитика последовательность состояний, в которых может оказаться объект при прохождении через определенный процесс,
С помощью диаграмм IDEF3 можно анализировать сценарии из реальной жизни, например, как закрывать магазин в экстренных случаях или какие действия должны выполнить менеджер и продавец п ри закрытии. Каждый такой сценарий содержит в себе описание процесса и может быть использован, что бы наглядно показать или лучше задокументировать бизнес-функции предприятия.
В отличие от классической методологии WFD в стандарте IDEF3 связи между работами делятся на три типа, обозначения, названия и смыл которых, приведены на рис. 3.16.
Существуют два типа диаграмм в стандарте IDEF3, представляющих описание одного и того же сценария технологического процесса в разных ракурсах:
диаграммы Описания Последовательности Этапов Процесса (Process Flow Description Diagrams, PFDD);
диаграммы Состояния Объекта и его Трансформаций в Процессе (Object State Transition Network, OSTN).
Предположим, требуется описать процесс окраски детали в производственном цеху на предприятии. С помощью диаграмм PFDD документируется последовательность и описание стадий обработки де тали в рамках исследуемого технологического процесса. Диаграммы OSTN используются для иллюстрации трансформаций детали, кото рые происходят на каждой стадии обработки.
Графические средства IDEF 3 позволяют документировать вышеуказанный производственный процесс окраски детали. В целом, этот процесс состоит непосредственно из самой окраски, производимой на специальном оборудовании и этапа контроля ее качества, который определяет, нужно ли деталь окрасить заново (в случае несоответ ствия стандартам и выявления брака) или отправить ее в дальнейшую
обработку.
Стрелки или линии являются отображением перемещения детали между иОВ-блоками в ходе процесса. Линии бывают следующих видов:
Старшая (Precedence) - сплошная линия, связывающая UOB. Рисуется слева направо или сверху вниз;
Отношения (Relational Link) - пунктирная линия, использующаяся для изображения связей между UOB;
Потоки объектов (Object Flow) - стрелка с двумя наконечниками используется для описания того факта, что объект (деталь) используется в двух или более единицах работы, например, когда объект порождается в одной работе и используется в другой.
Объект, обозначенный J1 - называется перекрестком (Junction). Перекрестки используются для отображения логики взаимодействия стрелок (потоков) при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fan-out Junction) стрелок. Перекресток не может использоваться одновременно для слияния и для разветвления. При внесении перекрестка в диаграмму необходимо указать тип перекрестка.
Все перекрестки в PFDD диаграмме нумеруются, каждый номер имеет префикс «J».
Сценарий, отображаемый на диаграмме, молено описать в следующем виде: деталь поступает в окрасочный цех, подготовленной к окраске. В процессе окраски наносится один слой эмали при высокой температуре. После этого, производится сушка детали, после которой начинается этап проверки качества нанесенного слоя. Если тест подтверждает недостаточное качество нанесенного слоя (недостаточную толщину, неоднородность и т.д.), то деталь заново пропускается через цех окраски. Если деталь успешно проходит контроль качества, то она отправляется в следующий цех для дальнейшей обработки.
Каждый функциональный блок UOB может иметь последовательность декомпозиций, и, следовательно, может быть детализирован с любой необходимой точностью. Под декомпозицией мы понимаем представление каждого UOB с помощью отдельной IDEF3 Диаграммы.
Например, мы можем декомпозировать UOB «Окрасить Деталь», представив его отдельным процессом и построив для него свою PFDD диаграмму. При этом эта диаграмма будет называться дочерней, по отношению к изображенной на рис. 3.18, а та, соответственно родительской. Номера UOB дочерних диаграмм имеют сквозную нумерацию, т.е., если родительский UOB имеет номер «1», то блоки UOB на его декомпозиции будут соответственно иметь номера «1.1». «1.2» и т.д. Применение принципа декомпозиции в IDEF 3 позволяет структурировано описывать процессы с любым требуемым уровнем детализа ции.
Если диаграммы PFDD технологический процесс «С точки зрения наблюдателя», то другой класс диаграмм IDEF3 OSTN позволяет рассматривать тот же самый процесс «С точки зрения объекта». Состояния объекта (в нашем случае детали) и Изменение состояния являются ключевыми понятиями OSTN диаграммы. Состояния объекта отображаются окружностями, а их изменения направленными линиями. Каждая линия имеет ссылку на соответствующий функциональный блок UOB, в результате которого произошло отображаемое ей изменение состояния объекта.
Первой работой является «Обработка заявок». Эта работа использует два объекта ссылок - «Заказы клиентов» и «Склад» - причем на диаграмме они показаны без деталей, т.к. не являются центральными для данной диаграммы. Работа «Обработка заявок» требует выпол нения одной из двух работ -либо «Оформление документов», либо «Дооформление заявок» (в случае, если заявка неверно оформлена). Ра бота «Дооформление заявок» использует ссылочный объект «Клиенты». Работа «Оформление документов» передает управление на две параллельные работы: «Формирование партии» и «Составление отчетности», причем работа «Формирование партии» также обращается к ссылочному объекту «Заказы клиентов». Как видно, на диаграмме есть два перекрестка ветвления, перекре сток с ветвлением по логическому исключающему «ИЛИ», и перекре сток с ветвлением по «И», означающим выполнение двух работ парал лельно.
Методология ARIS
В настоящее время наблюдается тенденция интеграции разнообразных методов моделирования, проявляющаяся в форме создания интегрированных средств моделирования. Одним из таких средств является программный продукт, носящий название ARIS (Architecture of Integrated Information Systems), разработанный германской фирмой IDS Scheer.
ARIS поддерживает четыре типа моделей (и множество видов моделей в каждом типе), отражающих различные аспекты исследуемой системы:
организационные модели, представляющие структуру системы - иерархию организационных подразделений, должностей и конкретных лиц, связи между ними, а также территориальную привязку структурных подразделений;
функциональные модели, содержащие иерархию целей, стоящих перед аппаратом управления, с совокупностью деревьев функций, необходимых для достижения поставленных целей;
информационные модели, отражающие структуру информации, необходимой для реализации всей совокупности функций системы;
модели управления, представляющие комплексный взгляд на реализацию бизнес-процессов в рамках системы.
Для построения перечисленных типов моделей используются как собственные методы моделирования ARIS, так и различные извест-
ные методы и языки моделирования, в частности, UML. Процесс моделирования можно начинать с любого из типов моделей.
Основная бизнес-модель ARIS - еЕРС (extended Event-driven Process Chain, расширенная модель цепочки процессов, управляемых событиями). Нотация ARIS еЕРС является расширением нотации IDEF3. Бизнес-процесс в нотации еЕРС представляет собой поток последовательно выполняемых работ (процедур, функций), расположенных в порядке их выполнения. Реальная длительность выполнения процедур в еЕРС визуально не отражается. Для получения информации о реальной длительности процессов необходимо использовать другие инструменты описания, например, MS Project.
Модели в ARIS представляют собой диаграммы, элементами которых являются разнообразные объекты - «функции», «события», «структурные подразделения», «документы» и т.д. Между объектами определённых видов могут быть установлены связи определённых видов («выполняет», «принимает решение», «должен быть проинформирован о результатах» и т.д.). Каждому объекту соответствует определенный набор атрибутов, которые позволяют ввести дополнительную информацию о конкретном объекте.
Платформа ARIS является специализированным набором инструментов для структурированного описания и анализа бизнес-процессов. В состав системы входят функциональные модули для:
Проектирования и оптимизации бизнес-процессов (ARIS Easy Design, ARIS Toolset, ARIS Business Design, ARIS Business Architect, ARIS Business Server);
динамического анализа и оптимизации бизнес-процессов (ARIS Simulation);
разработки и внедрения системы менеджмента качества (ARIS Quality Management Scout);
мониторинга и контроля эффективности бизнес-процессов (ARIS Process Perfomance Manager);
управления процедурами, обеспечивающими работу системы внутреннего контроля за формированием финансовой отчетности (ARIS Audit manager):
разработки, внедрения и поддержания системы управления операционными рисками (ARIS Process Risk Scout);
создания системы попроцессного калькулирования - Activity based costing (ARIS Process Cost Analyzer);
Проектирования системы сбалансированных показателей (ARIS
В ARIS существует более 130 различных способов графического представления моделей деятельности предприятия. Пример моделирования в нотации ARIS представлен на рис. 3.20. и в Приложении Д.
Преимущества. ARIS-платформа обладает большим набором функций. В ней предусмотрена возможность анализа построенных моделей бизнес-процессов, определения «узких» мест и оптимизации бизнес-процессов на основе анализа «что-если». Иными словами, пользователь может изменять те или иные бизнес-процессы, к примеру, перераспределить полномочия сотрудников и оценить, насколько увеличится время на выполнение тех или иных операций или стоимость работ. Модуль ARIS Process Cost Analyzer позволяет реализовать традиционную методологию Activity based costing для определения стоимости бизнес-процессов, а результаты использовать в модуле стратегического управления предприятием (ARIS BSC). Применяя дополнительные модули и внутренний язык программирования, пользователь может сформировать любые регламенты и положения, а также управлять рисками компании, создать систему менеджмента качества и внутреннего контроля.
Недостатки. К недостаткам можно отнести достаточно высокую стоимость программного обеспечения. Графическое представление моделей бизнес-процессов достаточно сложное для восприятия неподготовленных пользователей. Надо также отметить, что для использования.
Например, ЕМ Tool Kit требуется пройти учебный курс длительно стью два-три дня, а для освоения основных функциональных возможностей ARIS придется посетить несколько специализированных учеб ных курсов продолжительностью от пяти до пятнадцати дней.
К недостаткам функционального плана можно отнести подходы к реализации методологии попроцессного калькулирования. В системе отсутствует возможность задания как элементарных, так и сложных драйверов действий, то есть нельзя использовать сложные схемы распределения затрат между продуктами, услугами, клиентами и заказами.
Оплата безналичным расчетом
Рис. 3.20 - Модель верхнего уровня взаимосвязи ЗАТ НКМЗ с внешней средой в нотации AR1S Express
Моделирование бизнес-процессов -это
эффективное средство поиска путей оптимизации деятельности предприятия, позволяющее определить, как оно работает в целом и как организована деятельность на каждом рабочем месте.
Целью моделирования является систе матизация знаний о предприятии и его биз нес-процессах в наглядной графической фор ме более удобной для аналитической обработки полученной информации.
Анализ бизнес-процессов предприятия с разных точек зрения называется аудитом бизнес-процессов. Он проводится после создания и описания модели предприятия.
Под методологией (нотацией) создания модели (описания) бизнес-процесса понимается совокупность способов, при помощи которых объекты реального мира и связи между ними представляются в виде модели.
Модель бизнес-процесса -прикладное представление (в заданной нотации) исполняемых предприятием работ.
Выделяют следующие модели бизнес-процесса разной направленности: верхнего уровня, алгоритмическую, потоковую, функциональную.
Методология -это совокупность методов применяемых в жизненном цикле разработки системы (бизнес-процесса) и объединенных одним общим философским подходом.
Описание бизнес-процесса может производиться в текстовой форме, табличной форме, в виде алгоритмических схем.
Совокупность специальных графических элементов определяет нотацию моделирования.
Методологии моделирования бизнес-процессов классифицируют по трем категориям: 1) Методологии ведения проекта; 2) Методологии использования программных продуктов для моделирования бизнес-процессов в проекте; 3) Методологии моделирования и анализа бизнес-процессов.
Методологии ведения проектов связаны с изменением бизнес-процессов, существующих на предприятиях.
Методологии моделирования и анализа бизнес-процессов определяют руководящие указания для оценки и выбора проекта разрабатываемого программного продукта, шаги работы, которые должны быть вы-
полиены, их последовательность, правила распределения и назначения операций и методов.
SADT ( Structured Analysis and Design Tecchnique ) - методология структурного анализа и проектирования, которая породила целый ряд методов IDEFx . завоевавших особую популярность в задачах инжини ринга и реинжиниринга бизнес - процессов.
IDEFO - метод функционального моделирования позволяющий опи сать бизнес-процесс в виде иерархической системы взаимосвязанных функций.
IDEF 3 - метод описания процессов, рассматривающий последовательность выполнения и причинно-следственные связи между ситуациями и событиями для структурного представления знаний о системе.
DFD ( Data Flow Diagrams ) - диаграммы потоков данных - методо логия структурного анализа, описывающая внешние по отношению к си стеме источники и адресаты данных, логические функции, потоки дан ных и хранилища данных к которым осуществляется доступ.
1. Калянов Г.Н. Моделирование, анализ, реорганизация и автоматизация бизнес- процессов [Текст]: учеб. пособие для студ. вузов, обучающихся по специальности 080801 «Прикладная информатика (по областям)» и др. экон. специальностям. - М. : Финансы и статистика, 2007. - 240с.
Сериков А.В., Титов Н.В., Белоцерковский А.В., Лобанов А.В., Успаленко В.И. Компьютерное моделирование бизнес-процессов [Текст]: учеб. пособие для студ. вузов / Харьковский гос. технический ун-т строительства и архитектуры. - X. : Бурун Книга, 2007. -303 с.
Щенников С. Ю. Реинжиниринг бизнес-процессов. Экспертное моделирование, управление, планирование и оценка [Текст]. - М.:Ось-89, 2004. -288 с.
Робсон Майк, Уллах Филип. Реинжиниринг бизнес-процессов [Текст]: Практическое руководство / Л.Е. Долгова (пер.). - М. : ЮНИТИ, 2003. - 222 с.
Репин В.В., Елиферов В.Г. Процессный подход к управлению. Моделирование бизнес-процессов [Текст]. - М.: РИА «Стандарты и качество», 2004. - 408 с
а Шеер Август-Вильгельм. Моделирование бизнес-процессов [Текст]. - М.: Весть-МетаТехнология, 2000. - 206 с.
7 Виноградова О.В. Реінжиніринг бізнес-процесів торговельних підприємств [Текст]: Монографія. - Донецьк: ДонДУЕТ, 2006.- 183 с.
Виноградова О.В. Реінжиніринг бізнес-процесів у сучасному менеджменті [Текст]: Монографія. - Донецьк: ДонДУЕТ, 2005. - 195 с.
Ойхман Е.Г. Реинжиниринг бизнеса [Текст]/ Е. - М.: Финансы и статистика, 1997. - 336с.
Ю.Марка Д. Методология структурного анализа и проектирования.
[Текст] / Марка Д. - пер. с англ. - М. Финансы и статистика. -
2003. -240 с. H.Draheim, D. Business process technology: a unified view on business
processes, workflows and enterprise applications / Dirk
Draheim. - Berlin: Springer, 2010. - 323 p. 12.Holt, J. A Pragmatic guide to business process modelling / Jon
Holt. - British Informatics Society Ltd, 2009. - 246 p. 13.Laguna, M. Business process modeling, simulation and design /
Manuel Laguna, Johan Marklund. - Prentice Hall, 2005. - 429 p.
/. Что представляет собой процесс моделирования бизнес-процессов?
Назовите цель моделирования бизнес-процессов.
Перечислите преимущества моделирования.
Что называется аудитом бизнес-процессов?
Перечислите причины, по которым принимается решение по моделированию бизнес-процессов.
6 Что представляет собой модель в целом? 7 Раскройте сущность модели бизнес-процесса.
8 В чем состоит сущность нотации бизнес-процессов?
9- Перечислите виды моделей, которые могут применяться в дея тельности предприятия. Раскройте их сущность.
10. В каких формах может производиться описание бизнес-процесса? В чем их преимущества и недостатки? П. Что представляет собой методология?
По каким признакам классифицируют методологии моделирования бизнес-процессов?
Раскройте сущность методологий ведения проектов.
Обоснуйте необходимость применения методологий использования программных продуктов для создания моделей бизнес-процессов.
В чем состоит сущность методологии моделирования и анализа бизнес-процессов?
Перечислите основные исторические этапы развития методологий.моделирования бизнес-процессов.
В чем состоит многообразие «проекций» предприятия?
SADT . Охарактеризуйте типы данных моделей.
Какие основные элементы используются в модели по SADT ?
Раскройте историю появления методологии IDEFO .
Какие основные понятия лежат в основе методологии IDEFO ? Раскройте их содержание.
Какие составляющие имеет функциональный блок?
Охарактеризуйте виды интерфейсных дуг.
В чем заключается сущность принципа декомпозиции и в каких случаях декомпозиция выполняется?
Для чего необходим глоссарий?
В каких случаях используются диаграммы потоков данных DFD (Data Flow Diagrams )?
Перечислите и раскройте сущность основных элементов DFD диаграмм.
Раскройте сущность методологии DFD в нотациях Гейна-Сарсона и Иордана-Де Марко. В чем их сходства и отличия?
Для каких целей был разработан стандарт IDEF 3?
Назовите основные отличия стандарта 1 DEF 3 от классической методологии WFD .
Какие два типа диаграмм используются в стандарте IDEF 3?
І.Что понимают под моделированием бизнес-процессов?
а) это комплексный инструмент поиска путей оптимизации деятельности предприятия, позволяющее определить, как оно работает в целом и как организована деятельность на каждом рабочем месте;
б) это эффективное средство поиска путей оптимизации деятель ности предприятия, позволяющее определить, как оно работает в целом и как организована деятельность на каждом рабочем месте;
в) это универсальное средство поиска путей оптимизации дея тельности предприятия, позволяющее определить, как оно ра ботает в целом и как организована деятельность на каждом ра бочем месте.