Создание схемы IDEF0
IDEF0 обозначает определение интеграции для моделирования процессов — методологию создания общедоступных доменов, которая используется для моделирования предприятий и их процессов, чтобы их можно было понять и улучшить. Это тип схемы.
Схемы IDEF0 обычно включают следующие компоненты:
- Контекстная схема — самая верхняя схема в модели IDEF0.
- Иерархия декомпозиции IDEF0 с использованием родительских и детских связей.
- Дерева узлов — структуры узлов в виде дерева, корневые на выбранном узле и используемые для представления полного декомпозиции IDEF0 в одной схеме.
Создание контекстной схемы
- Откройте Visio.
- В Visio 2013 и более новых версиях: щелкните категорию «Диаграммы», выберите IDEF0 Diagram (Схема IDEF0) и нажмите кнопку Create (Создать). In Visio 2010: Under Template Categories, click Flowchart >IDEF0 Diagram >Create. В Office Visio 2007: в меню Файл найдите пункты Новые ,Навести указатель мыши на пункт«Схема» и выберите пункт Схема IDEF0.
- Добавьте блок заголовка, чтобы уложить имя узла, заголовок и номер для схемы.
- Перетащите фигуру Блок заголовка из фигур схемы IDEF0на страницу.
- В диалоговом окне Данные фигуры введите имя узла, например A-0 (минус ноль) или более полное имя, например QA/A-0, где qa — это сокращение имени модели. Вы также можете ввести название и номер схемы. Выберите расстояние от внешнего края страницы до границы блока заголовка и нажмите кнопку ОК.
- Из фигур схемы IDEF0перетащите фигуру «Действие» внутри блока заголовка.
- В диалоговом окне Данные фигуры введите имя процесса. В качестве ИД процессаиспользуйте по умолчанию A0, чтобы представить процесс верхнего уровня. В качестве ИД под-схемывведите ИД схемы декомпозиции, если этот процесс является декомпозицией.
- Из фигур схемы IDEF0перетащите на страницу схемы одну разборную фигуру соединителевой схемы и перетащите конечные точки к точкам соединения в полях действий.
- Чтобы добавить текст с описанием соединителю, вы выберите ее и введите текст.
- Из фигур схемы IDEF0перетащите фигуру Блок текста 8 пт на страницу документа внутри блока заголовка.
- Перетащите боковой лад, чтобы растянуть блок текста по ширине блока заголовка.
- Выделив фигуру, введите текст, чтобы описать, для какой модели она предназначена.
Создание родительской или детской схемы
- Откройте Visio.
- В Visio 2013 и более новых версиях: щелкните категорию «Диаграммы», выберите IDEF0 Diagram (Схема IDEF0) и нажмите кнопку Create (Создать). In Visio 2010: Under Template Categories, click Flowchart >IDEF0 Diagram >Create. В Visio 2007: в меню Файл найдите пункты Новые ,Навести указатель мыши на пункт«Схема» и выберите пункт Схема IDEF0.
- Добавьте блок заголовка, чтобы уложить имя узла, заголовок и номер для схемы.
- Из фигур схемы IDEF0перетащите фигуру Блок заголовка на страницу.
- В диалоговом окне Данные фигуры введите имя узла, например A0 (для самой верхней родительской схемы), или номер узла родительской функции (например, A3 или A112), если родительская схема также является родительской схемой. Вы также можете ввести заголовок и номер. Выберите расстояние от внешнего края страницы до границы блока заголовка и нажмите кнопку ОК.
- Из фигур схемы IDEF0перетащите фигуру «Действие» в блок заголовка.
- В диалоговом окне Данные фигуры введите имя процесса, который представляет поле. (Имя должно быть активным глаголом или глагольным словосочетанием.) Введите ИД процесса (число от 1 до 6) и подстраховую схему. В под-схеме (также известной как выражение подробных ссылок или DRE) находится номер подчиненной схемы этого окна действия, если он будет иметь такой. В под-схеме может быть номер узла, например A42, либо номер страницы или имя подчиненной схемы.
- Продолжайте перетаскивание, присвоение имен и нумингу полей, пока в блоке заголовка не будет от трех до шести полей.
- Из фигур схемы IDEF0перетащите соединителон IDEF0 на страницу, а затем перетащите его конечные точки к точкам соединения в полях действий. Когда конечные точки поворачиваться красным цветом, фигуры соединены.
- Перетащите второй соединителка IDEF0 на страницу и перетащите его точки к точке соединения в другом поле действия.
- Поместите стрелку второго соединитела непосредственно на стрелку первого соединитела, чтобы две стрелки были соединены друг с другом.
Создание стрелок для висячай
- Из фигур схемы IDEF0перетащите соединителон IDEF0 на страницу, а затем перетащите его конечные точки к точкам соединения в полях действий. Когда конечные точки поворачиваться красным цветом, фигуры соединены.
- Перетащите на страницу второй соединителся IDEF0 и выровняте его точки с первой.
- Перетащите конечную вверх или вниз, пока стрелки не разорвятся нужным образом.
- Повторяйте шаги 1—3, пока не у вас будет нужное количество вилок.
Создание стрелок, которые раздувайте в ветви
- Перетащите соединителку IDEF0 на страницу, а затем перетащите точки к точке соединения в поле действия. Когда начальная точка становится красной, фигуры соединены.
- Перетаскивать стрелку, пока соединитектор не будет изгибаться нужным образом.
- Выбрав соединитель, перетащите копию соединителя в то место, куда нужно ввести первую ветвь, удерживая на клавише CTRL.
- Нажмите клавишу F4, чтобы создать нужное количество дополнительных ветвей.
- Подключение конечные точки в соответствующие поля действий.
Совет: Чтобы лучше выровнять ветви, соедините точки начала дубликаты ветвей с точки начала исходной ветви. Если ваши ветви имеют два изгиба, можно также использовать для положение центрального отгона соединителения.
Создание стрелок для этого канала
- Из фигур схемы IDEF0перетащите соединителон IDEF0 на страницу, а затем перетащите его конечные точки к точкам соединения соответствующим полям действий. Когда конечные точки поворачиваться красным цветом, фигуры соединены.
- Чтобы добавить канал, щелкните соединителю правой кнопкой мыши и выберите Tunnel В или Tunnel Выход. Чтобы удалить соединителку, щелкните его правой кнопкой мыши и выберите Tunnel В или Tunnel выход, чтобы снять его.
Примечание: Используйте фигуру соединителю с разборкой в виде разборки, чтобы добавить стрелки прямой линии на схему IDEF0.
Создание дерева узлов
- Откройте Visio.
- В Visio 2013 и более новых версиях: щелкните категорию «Диаграммы», выберите IDEF0 Diagram (Схема IDEF0) и нажмите кнопку Create (Создать). In Visio 2010: Under Template Categories, click Flowchart >IDEF0 Diagram >Create. В Visio 2007: в меню Файл найдите пункты Новые ,Навести указатель мыши на пункт«Схема» и выберите пункт Схема IDEF0.
- Добавьте узел на схему.
- Перетащите фигуру Узел на страницу чертежа.
- В диалоговом окне Данные фигуры введите A0 либо номер узла или имя узла, для которого нужно корневое дерево, и нажмите кнопку ОК.
- Чтобы добавить текстовую метку на узел, перетащите на страницу документа фигуру Блок текста 8 пт. Выбирая блок текста, введите метку.
- На схеме дерева узла IDEF0 щелкните правой кнопкой мыши узел, который вы хотите изменить,и выберите установить номер узла .
- В диалоговом окне Данные фигуры введите нужное число и нажмите кнопку ОК.
- Чтобы изменить положение номера узла, перетащите связанный с ним лад.
Совет: Если вы хотите прямо с узла перейти к подробной схеме, в которую он входит, добавьте гиперссылки на узел, а затем привяжете ее на страницу схемы, содержаную подробную схему.
Лабораторная работа 3. Схемы визуального моделирования в среде Microsoft Visio
Бизнес-процессы, массивы (потоки) данных можно представить графически в виде схем. Такой способ моделирования называется визуальным. Его основное отличие и преимущество — простота и наглядность. В ряде случаев он является альтернативой математической модели, или визуальные и математические модели могут использоваться совместно. Для профессионального визуального моделирования предназначены системы CASE-средств: СА Erwin Proces Modeler (BPwin), CA Erwin Data Modeler (ERwin), Rational Rose и др.
Зная правила построения визуальных моделей, например методологии IDEFO, IDEF3, можно создать простую модель без привлечения программных продуктов, реализующих CASE-средства.
Требуется по методологии IDEF0 построить модель бизнес-процес-са продажи техники, состоящую из трех работ, и для одной из работ создать модель данных. Для этого выполнить следующие действия:
- 1. Открыть файл с результатами лабораторной работы № 2.
- 2. На ярлыке страницы Поиск чисел по условию выполнить контекстную программу Добавить страницу (Insert Page). Присвоить имя IDEF0 новой странице.
- 3. Щелчок по кнопке Фигуры (Shapes). Выбрать Блок-схема / Фигуры схемы IDEFO» (Flowchart / IDEFO Diagram Shapes).
- 4. На панели инструментов выбрать масштаб 130 %.
- 5. Перетащить элемент Блок заголовка (Title Block) и в окне Данные фигуры (Custom Properties) ввести данные:
- — в строке Узел (Node) окна -АО;
- — в строке Заголовок (Title) — Деятельность компании;
- — в строке Номер (Number) -1;
- — в строке Поля страницы (Page Offset) -12,5 мм, ОК (рис. 3.1).
Рис. 3.1. Начальный ввод данных
- 6. Форматировать заголовочные области в нижней части рамки. Для этого выполнить следующие действия:
- — при нажатой клавише Ctrl выделить области Узел (Node), Заголовок (Title), Номер (Number). Выделенные области указаны на рис. 3.1;
- — контекстной командой Формат / Текст / Шрифт (Format / Text / Font) установить высоту шрифта 12 пт (pt), Применить (Apply), ОК. Для снятия выделения щелкнуть вне выделенной области на пустом месте;
- — выделить область Узел (Node) и выполнить контекстную команду Формат / Текст / Абзац / Первая строка (Format / Text I Paragraph / First Line), выбрать 8 мм. При этом по умолчанию установлено выравнивание По правому краю (Right). Результат представлен на рис. 3.2;
- — щелчок по тексту АО — выделится блок (рис. 3.2); на панели инструментов выбрать высоту шрифта 14 пт (pt);
Рис. 3.2. Форматирование области Узел
— выделить область заголовка (рис. 3.3):
Деятельность компании ЗАГОЛОВОК:» НОМЕР:
Рис. 3.3. Выделение области Заголовок
— выполнить контекстную команду Формат / Текст / Абзац / Первая строка (Format / Text / Paragraph / First Line), выбрать 100 мм. При этом по умолчанию установлено выравнивание По правому краю (Right). Результат представлен на рис. 3.4:
Деятельность компании NUMBER:
Спутниковые и радиорелейные системы передачи данных
quality .eup.ru
Вероятно, самый старый в рунете сайт о менеджменте качества
Стратегическое планирование имеет дело не с будущими решениями, а с будущим решений, принимаемых сегодня. (П. Дракер)
Проблемы описания бизнес-процессов в виде потоков работ (IDEF3, ARIS eEPC)
Обзор посвящен вопросам формирования моделей бизнес-процессов, используемых для регламентации и управления. Рассматривают проблемы, связанные с описанием бизнес-процессов в виде потоков работ ( Work flow ). При построении таких моделей особенно остро встает вопрос описания деятельности руководителя (владельца процесса).
Модели потоков работ ( ARIS eEPC , IDEF3, блок схемы в Visio ) предназначены для подробного описания операций (работ), выполняемых последовательно во времени по определенной технологии. Эти модели (нотации), особенно ARIS eEPC , активно используются в настоящее время на практике. Крупнейшие российские компании приобрели систему ARIS Toolset и занимаются описанием бизнес-процессов, в основном, в нотации eEPC . Другие компании ориентируются на IDEF 3 и систему BPWin . На практике возникает ряд проблем, связанных с применение указанных моделей, которые целесообразно разделить на две группы:
1) проблемы, связанные с отсутствием понимания сути процесса и процессного подхода и, как следствие, некорректная постановка задачи описания процессов с использованием потоковых диаграмм;
2) неумение эффективно использовать сами модели при описании бизнес-процессов.
Когда в организации бизнес-процесс понимается как плоская графическая схема, дело внедрения процессного подхода (описания, реорганизации и управления процессами), без сомнения, обречено на неудачу. В своей практике процессного консалтинга мы наблюдаем много таких примеров. В чем же основная проблема, как эффективно описывать и регламентировать бизнес-процесс, как отобразить в модели деятельность руководителей? В этом обзоре мы коснемся только одного аспекта, связанного с созданием моделей процессов, учитывающих деятельность руководителей. В последующих статьях будет подробно раскрыт комплексный подход к описанию, регламентации и управлению процессами.
Что значит фраза «описать бизнес-процесс», что кроется за этой краткой формулировкой? Прежде чем дать ответ на этот вопрос, отметим, что схемы процессов рассматриваются нами в качестве одного из необходимых элементов описания процессов, но далеко на самого важного. Для целей дальнейшего изложения сделаем несколько необходимых определений.
Бизнес-процесс — устойчивая, целенаправленная совокупность взаимосвязанных видов деятельности (последовательность работ), которая по определенной технологии преобразует входы в выходы, представляющие ценность для потребителя.
Владелец бизнес-процесса – должностное лицо, которое имеет в своем распоряжении персонал, инфраструктуру, программное и аппаратное обеспечение, информацию о бизнес-п роцессе, управляет ходом бизнес- процесса и несет ответственность за результаты и эффективность бизнес- процесса.
Вход бизнес- процесса – ресурс, необходимый для выполнения бизнес-процесса.
Выход бизнес- процесса – результат (продукт, услуга) выполнения бизнес-процесса.
Модель – графическое, табличное, текстовое, символьное описание бизнес-процесса либо их взаимосвязанная совокупность.
Поставщик — субъект, предоставляющий ресурсы.
Потребитель (клиент) – субъект, получающий результат бизнес-процесса. Потребитель может быть:
а) внутренний – то есть находящийся в организации и, в ходе своей деятельности, использующий результаты (выходы) предыдущего бизнес- процесса;
б) внешний – то есть находящийся за пределами организации и использующий или потребляющий результат деятельности (выход) организации.
Операция (работа) – часть бизнес-процесса.
Регламент бизнес-процесса – документ, описывающий последовательность операций, ответственность, порядок взаимодействия исполнителей и порядок принятия решений по улучшениям.
Ресурсы – информация (документы, файлы), финансы, материалы, персонал, оборудование, инфраструктура, среда, программное обеспечение, необходимые для выполнения бизнес-процесса.
Функция – направление деятельности элемента организационной структуры, представляющие собой совокупность однородных операций, выполняемых на постоянной основе.
IDEF 0 – – FIPS 183 США « Integration definition for function modeling ( IDEF 0)» – «Интеграционное определение для моделирования функций»
IDEF 3 – ( workflow modeling , Р rocess Description Capture Method ) методология описания бизнес-процессов (потоков работ).
Наше определение бизнес-процесса основано на определении, сформулированном в стандарте ISO -9001:2000. Мы считаем, что это наиболее адекватное, практически важное определение. Из него вытекают требования к описанию бизнес-процесса и подходы к его управлению. В нашем понимании описать бизнес-процесса означает:
1) определить владельца бизнес-процесса;
2) определить границы бизнес-процесса (границы ответственности и полномочий владельца процесса по управлению процессом);
3) определить клиентов и выходы бизнес-процесса;
4) определить поставщиков и входы бизнес-процесса;
5) определить ресурсы, необходимые для выполнения бизнес-процесса (- находятся в распоряжении владельца процесса);
6) описать технологию выполнения бизнес-процесса (например, с использованием графических схем в выбранных нотациях);
7) разработать показатели, по которым оценивается бизнес-процесс, его результаты и удовлетворенность клиентов бизнес-процесса;
8) описать работу владельца по анализу и улучшению бизнес-процесса, а так же его отчетность перед вышестоящим руководителем.
Управление бизнес-процессом осуществляется по определенным технологиям и с использованием определенных документов, в число которых входят: регламент выполнения бизнес-процесса, положение о подразделении, должностные и рабочие инструкции, методические документы по измерению показателей бизнес-процессов, отчетные формы, спецификации входов/выходов и т.д. (см. рисунок 1).
Рисунок 1. Документы, используемые при управлении бизнес-процессом.
Таким образом, задача регламентации и эффективного управления бизнес-процессом не сводится к разработке только графических схем процессов. Графические схемы (модели) бизнес-процессов являются только частью документации, как правило, несущей информацию по пошаговой технологии выполнения процесса. Важно понимать, что помимо разработки графических схем необходимо выполнить много другой, важной работы по описанию и регламентации процесса.
Обратимся собственно к графическим схемам или, другими словами, моделям бизнес-процессов. В настоящее время для целей описания бизнес-процессов часто используют схемы потоков работ ( Work Flow ): ARIS eEPC , IDEF 3, блок-схемы в Visio или MS Word . В основе указанных подходов лежит принцип построения бизнес-процесса в виде последовательно выполняемых во времени операций (работ), как показано на рисунке 2.
Рисунок 2. Пример схемы потока работ.
Модель потока работ состоит из операций (работ), символов логики , стрелок. Логические символы или, как их принято называть в IDEF 3, перекрестки представляют собой логическое «И», логическое «ИЛИ», исключающее «ИЛИ». Они служат для отображения ветвления и слияния процесса. Стрелки могут использоваться для отображения последовательности выполнения операций во времени или потока объектов (документы, ресурсы). В различных подходах (нотациях) в модели потока работ могут отображаться исполнители, документы, используемое оборудование, программные средства и т.д. Суть схем процессов от этого не изменяется – модели остаются плоскими и показывают поток работ, переходящий от одного рабочего места к другому.
При построении моделей потоков работ можно использовать декомпозицию, когда каждая операция описывается более подробно на отдельном листе в виде модели в той же (или другой) нотации. При проведении декомпозиции возникает ряд проблем с увязкой моделей на разных уровнях и моделей в рамках одного уровня. Так как они являются преимущественно техническими, то рассматриваться в нашем обзоре не будут.
Остановимся на следующем вопросе. Если мы хотим использовать схему бизнес-процесса для регламентации (например, в документе «Регламент выполнения бизнес-процесса»), то эта схема должна удовлетворять следующим требованиям:
1) все отображенные на схеме операции бизнес-процесса должны существовать реально и быть закрепленными за конкретными исполнителями;
2) на схеме должны отображаться реальные документы, файлы, ресурсы;
3) схема процесса должна быть проста и понятна для визуального восприятия;
4) схема процесса должна иметь компактный размер.
Эти требования означают, что строить потоковую диаграмму имеет смысл при описании операций уровня рабочего места исполнителя, в крайнем случае – для –операций небольшого (3-4 человека) подразделения. На более крупном уровне модели потоков работ могут дать общую информацию о процессе, но использовать такие модели для регламентации затруднительно вследствие размывания ответственности между исполнителями процесса.
Если мы описываем бизнес-процесс на детальном уровне, то на выходе этой работы получаем схемы, содержащие поток операций и их исполнителей. Именно при формировании таких моделей и возникает важнейшая, на наш взгляд, проблема: из рассмотрения полностью исключаются руководители. Возникает следующая ситуация. Группа аналитиков (или внутренних экспертов) приходит в подразделение, получает разрешение руководителя, начинает работать с исполнителями процесса, переходя от одного рабочего места к другому в соответствии с ходом движения бизнес-процесса.
Формируется модель бизнес-процесса, включающая операции всех рядовых исполнителей, но лишенная даже намека на руководителей, владельцев бизнес-процесса. Кроме того, такие модели чаще всего описывают нормальный ход бизнес-процесса. Возможные отклонения очень часто остаются вне рассмотрения. Так же часто опускают такие важные моменты, как: действия при получении не соответствующих входов (например, документ из соседнего подразделения), получение несоответствующих требованиям выходов (брак, недоработка), регистрацию параметров процесса (измерения), контроль и т.д. Нужен ли такой результат работы руководителю? Ответ очевиден. Полученные схемы бизнес-процесса являются плоскими, неполными, не могут эффективно использоваться для внедрения системы процессного управления. Тем не менее, многие компании, особенно крупные, выполняют отдельные проекты по созданию внутренних стандартов моделирования «плоских» бизнес-процессов, «создания баз знаний компании по бизнес-процессам» и т.п. В итоге, полученные «горы» четко структурированной, но «однобокой», неполной информации оказываются практически бесполезными для целей реального управления.
На рисунке 3 показан «объемный» бизнес-процесс. Он состоит из нескольких моделей потоков работ, сформированных для каждого уровня: исполнители, зам. руководителя, руководитель (владелец) бизнес-процесса
Рисунок 3. «Объемный бизнес-процесс».
На рисунке 3 видно, что руководитель и его заместитель активно участвуют в процессе. Существует постоянный, цикличный поток информации по ходу процесса от исполнителей — вверх, и управленческих решений от руководителей — вниз. Даже если (в предельном случае) мы полностью делегируем все права на принятие управленческих решений по процессу исполнителям, у руководителя останется ключевая функция – анализ эффективности бизнес-процесса и его улучшение с ориентиром на стратегические цели компании (если таковые имеются). Улучшение процесса руководитель осуществляет за счет управления ресурсами: персонал, финансы, материалы, оборудование, программное обеспечение, информация и т.д.
Каким же образом увязать деятельность руководителей и исполнителей при построении моделей потоков работ ( ARIS eEPC , IDEF 3)? Очевидно, что сделать это можно несколькими способами. Первый и самый простой способ состоит в следующем: отдельно описываются потоки работ, выполняемых как руководителями, так и исполнителями. Такой простейший подход имеет несколько недостатков, основной их которых состоит в том, что взаимодействие руководителя и исполнителя становится в модели неявным, а опосредованным при помощи обратных связей по информации. Другой способ состоит в том, что при описании работ исполнителей можно указать прямые ссылки на процессы, выполняемые руководителями, или прямо отобразить их вмешательство в работу. Сказанное иллюстрирует рисунок 4.
Рисунок 4. От «плоского» процесса к «объемному».
На рисунке 4, вверху показана простейшая цепочка бизнес-процесса, состоящая из двух операций. Представим себе, что эти операции выполняются исполнителем и требуют управления со стороны руководителя. Как мы можем отобразить этот факт на модели? Согласно первому предложенному выше способу, мы указываем на модели процесса обратную связь по информации. В данном примере, нотация ARIS eEPC позволяет показать входящий и исходящий документ А, содержащий некоторую информацию. Документ А попадает от исполнителя руководителю после выполнения функции 2, и затем может быть возвращен на доработку при выполнении функции 1. При этом, «где-то в другом месте» мы должны описать работу руководителя по проверке этого документа и принятию решения. Это означает, что мы должны создать модель, описывающую деятельность руководителя.
На рисунке 4 приводится еще два способа «встраивания» руководителя в бизнес-процесс. Первый из них предполагает прямое включение в процесс «Функции управления», второй – в виде дополнительного события «Принято управленческое решение».
Какой способ для отображения участия руководителя в бизнес-процессе выбрать? Это определяет сама организация. Можно составить схему бизнес-процесса уровня исполнителей, а деятельность руководителя расписать в виде подробной таблицы с указанием операций, входящих и исходящих документов, принимаемых решений. Можно сформировать схемы процесса для работы самого руководителя. Можно пытаться отобразить участие руководителя на одной плоской схеме, увеличивая количество возможных ветвлений и слияний процесса. Мы считаем, что нужно выбирать тот способ, который наилучшим образом подходит для последующей регламентации и управления бизнес-процессом. Моделируя, главное не забыть про руководителя, поскольку именно он отвечает за управление и улучшение бизнес-процесса и, в конечном счете, модели бизнес-процессов создаются именно для него.
Практическая работа «Построение диаграммы потоков данных DFD и диаграмм IDEF3 в Мicrosoft Visio 2010» МДК 01.02 «Методы и средства проектирования ИС» Специальность 09.02.04 «Информационные технологии (по отраслям)»
· построить диаграмму декомпозиции в нотации IDEF 3 одной из работ диаграмм IDEF0.
Диаграммы потоков данных (Data flow diagram, DFD) используются для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет моделируемую систему как сеть связанных между собой работ. Их можно использовать как дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота в корпоративных системах обработки информации. Главная цель DFD — показать, как каждая работа преобразует свои входные данные в выходные, а также выявить отношения между этими работами.
Любая DFD-диаграмма может содержать работы, внешние сущности, стрелки (потоки данных) и хранилища данных.
Работы. Работы изображаются прямоугольниками с закругленными углами, смысл их совпадает со смыслом работ IDEF0 и IDEF3. Так же как работы IDEF3, они имеют входы и выходы, но не поддерживают управления и механизмы, как IDEF0. Все стороны работы равнозначны. В каждую работу может входить и выходить по несколько стрелок.
Если в процессе моделирования нужно осветить специфические стороны технологии предприятия, BPwin позволяет переключиться на любой ветви модели на нотацию IDEF3 или DFD и создать смешанную модель.
Диаграммы потоков данных ( Data Flow Diagramming ) (DFD) используются для описания документооборота и обработки информации. Нотация DFD включает такие понятия, как «внешняя ссылка» и «хранилище данных», что делает ее более удобной (по сравнению с IDEF0) для моделирования документооборота.
На рис. 1 представлена «Диаграммы декомпозиции в нотации DFD. Резервирование номеров.», описывающая деятельность по резервированию номеров. На диаграмме представлены:
1) «Клиента» и «Персонал » – это внешние ссылки, источник данных из вне модели.
2) «Устав гостиницы» и «Данные о номерах гостиницы» – хранилища данных.
Эти данные хранятся на данный момент в бумажном эквиваленте. Наше клиентское приложение позволит все эти данные хранить в электронном виде и облегчит обновление данных о номерах гостиницы и постояльцах.
Рисунок 1 — Диаграммы декомпозиции в нотации DFD. Резервирование номеров.
В отличие от стрелок IDEF0, которые представляют собой жесткие взаимосвязи, стрелки DFD показывают, как объекты (включая данные) двигаются от одной работы к другой. Например, «Заказ» в какой-либо форме (телеф. звонок или электрон. письмо на адрес гостиницы), приходит от клиента и инициирует процедуру «Обработки заказа» . Эту процедуру выполняет «Персонал», в чьи обязанности это входит. Персонал запрашивает «Данные о номерах» из хранилища данных (гостиничный журнал или электрон. БД) и, согласуясь с «Правилами предоставления номеров» (содержащимися в уставе гостиницы ), отказывает клиенту в резервировании номера или:
после «оформления заказа номера» обновляет данные о номерах – заносит «Обновленные данные о номерах» в хранилище «Данных о номерах гостиницы».
На рис. 2 представлена «Диаграммы декомпозиции в нотации DFD. Оформление поселения.», описывающая деятельность по оформлению поселения. На диаграмме представлены:
3) «Клиента» и «Персонал » – это внешние ссылки, источник данных из вне модели.
4) «Устав гостиницы» , «Документы клиенты» (паспорт в бумажном виде или другой удостоверяющий личность документ), «Законы РФ», «Данные о номерах гостиницы» – хранилища данных.
Все работы, представленные на диаграмме выполняются «Персоналом» в соответствие с «Перечнем обязанностей». Клиент запрашивает номер в гостинице («Отказ» возможен в случае отсутствия свободных номеров в гостинице) или активизирует свой «Зарезервир. номер». Если после «Обработки запроса» с участием «Данных о номерах» из хранилища, запрос удовлетворяется :
постоялец предъявляет свои «Документы», выбирает тарифы проживания, проходит регистрацию и получает ключи от номера:
«Персонал» оформляет въезд постояльца и обновляет данные о номерах гостиницы в хранилище «Данных о номерах гостиницы»
Все это «Персонал» делает, руководствуясь «правилами поселения», прописанными в «Уставе гостиницы», и «Законами и постановлениями » РФ, регламентирующими, например, обязательную идентификацию личности граждан при поселении в гостинице.
Рисунок 2 — Диаграммы декомпозиции в нотации DFD. Оформление поселения.
Диаграммы методологии IDEF 3 ( Workflow Diagramming )
Для описания логики взаимодействия информационных потоков более подходит workflow diagramming. Диаграммы Workflow могут быть использованы в моделировании бизнес-процессов для анализа завершенности процедур обработки информации.
На Диаграмме декомпозиции в нотации IDEF3. Проверка счетов (на рис. 3) иллюстрируется «Проверка счетов».
Как только счет запрошен, запускаются все последующие за перекрестком (AND) процессы:
«Формирование счета за тел. переговоры»;
«Формирование счета за услуги»;
запускается «Анализ сроков пребывания» постояльца в гостинице, по окончании которого запускается процесс «Формирования счет за проживание», учитывающий в своей работе «Результаты анализа».
«Учет» – это стрелка отношения (Relational Link). Мы использовали ее для изображения связи между процессом «Формирования счета за проживание» объектом ссылки «Внесенная предоплата», учет которого важен для результатов процесса.
Стрелки с двумя наконечниками: «Счет за проживание», «Счет за тел. переговоры» и «Счет за услуги» – обозначают потоки объектов (Object Flow). В данном случае, мы их применяем для описания того факта, что эти объекты порождается в одной работе(«Формирование счета…») и используется в процессе «Формирования итогового счета».
В ходе практической работы мы автоматизируем работы 2, 3, 4, 5.
Рисунок 3 — Диаграммы декомпозиции в нотации IDEF3. Проверка счетов
Диаграмма дерева узлов показывает иерархию работ в модели и позволяет рассмотреть всю модель целиком, но не показывает взаимосвязи между работами.
На рис. 4 представлено итоговое расположение работ в дереве узлов:
диаграмма «Функционирование гостиницы» – 1-ый уровень дерева узлов (top level activity);
диаграммы «Предоставление номеров», «обслуживание номеров» и «Обеспечение телефонных переговоров» – 2-ой уровень дерева узлов;
диаграммы «Резервирование номеров», «Оформление поселения», «Прием предоплаты», «Проверка счетов», «Подготовка номеров» – 3-ий уровень;
диаграммы «Обработка заказа», «Обновление данных о номерах», «Обработка запроса», «Обновление данных» и «Оформление въезда» – 4-ый уровень дерева узлов, последний уровень декомпозиции – необходимая в ходе нашего курсового проектирования степень подробности.
Рисунок 4 — Диаграмма дерева узлов