IDEF0 - нотация графического моделирования, используемая для создания функциональной модели, отображающей структуру и функции системы, а также потоки информации и материальных объектов, связывающих эти функции. Стандарт IDEF0 (Integration Definition for Function Modeling) утвержден в США в 1993 как Федеральный стандарт обработки информации. В России находится в статусе руководящего документа с 2000 года и в настоящее время в качестве стандарта не утвержден. Тем не менее методология IDEF0 является одним из популярных подходов для описания бизнес-процессов. К ее особенностям можно отнести:
использование контекстной диаграммы;
поддержка декомпозиции;
доминирование;
выделение 4 типов стрелок.
Контекстная диаграмма. Самая верхняя диаграмма, на которой объект моделирования представлен единственным блоком с граничными стрелками. Эта диаграмма называется A-0 (А минус нуль). Стрелки на этой диаграмме отображают связи объекта моделирования с окружающей средой. Диаграмма A-0 устанавливает область моделирования и ее границу. Пример диаграммы A-0 приведен на Рис. 1.
Рисунок 1. Диаграмма A-0 в нотации IDEF0
Поддержка декомпозиции. Нотация IDEF0 поддерживает последовательную декомпозицию процесса до требуемого уровня детализации. Дочерняя диаграмма, создаваемая при декомпозиции, охватывает ту же область, что и родительский процесс, но описывает ее более подробно. Согласно методологии IDEF0 при декомпозиции стрелки родительского процесса переносятся на дочернюю диаграмму в виде граничных стрелок.
Доминирование. Блоки модели IDEF0 на неконтекстной диаграмме должны располагаться по диагонали - от левого верхнего угла диаграммы до правого нижнего в порядке присвоенных номеров. Блоки на диаграмме, расположенные вверху слева, "доминируют" над блоками, расположенными внизу справа. "Доминирование" понимается как влияние, которое блок оказывает на другие блоки диаграммы. Расположение блоков на листе диаграммы отражает авторское понимание доминирования. Таким образом, топология диаграммы показывает, какие функции оказывают большее влияние на остальные.
Выделение 4 типов стрелок. Выделяются следующие типы стрелок: "Вход", "Выход", "Механизм", "Управление". Входы преобразуются или расходуются процессом, чтобы создать то, что появится на его выходе. Управления определяют условия, необходимые процессу, чтобы произвести правильный выход. Выходы - данные или материальные объекты, произведенные процессом. Механизмы идентифицируют средства, поддерживающие выполнение процесса. Таким образом, блок IDEF0 показывает преобразование входа в выход с помощью механизмов с учетом управляющих воздействий.
Описание назначения графических символов, используемых в нотации IDEF0, приведено в Таблице 1.
| Название | Графический символ | Описание |
|---|---|---|
 | Процесс обозначается прямоугольным блоком. Внутри каждого блока помещается его имя и номер. Имя должно быть активным глаголом, глагольным оборотом или отглагольным существительным. Номер блока размещается в правом нижнем углу. Номера блоков используются для идентификации на диаграмме и в соответствующем тексте. | |
 | Стрелки обозначают входящие и исходящие из процесса объекты (данные). Каждая сторона функционального блока имеет стандартное значение с точки зрения связи блок-стрелка. В свою очередь, сторона блока, к которой присоединена стрелка, однозначно определяет ее роль. Стрелки, входящие в левую сторону блока - входы. Стрелки, входящие в блок сверху - управления. Стрелки, покидающие процесс справа - выходы, т.е. данные или материальные объекты, произведенные процессом. Стрелки, подключенные к нижней стороне блока, представляют механизмы. |
|
| Туннелированная стрелка |   | Туннелированные стрелки означают, что данные, передаваемые с помощью этих стрелок, не рассматриваются на родительской диаграмме и/или на дочерней диаграмме. Стрелка, помещенная в туннель там, где она присоединяется к блоку, означает, что данные, выраженные этой стрелкой, не обязательны на следующем уровне декомпозиции. Стрелка, помещаемая в туннель на свободном конце, означает, что выраженные ею данные отсутствуют на родительской диаграмме. Туннелированные стрелки могут быть использованы на диаграммах процессов в нотациях IDEF0, "Процесс", "Процедура". |
| Элемент обозначает место, сущность или субъект, которые находятся за границами моделируемой системы. Внешние ссылки используются для обозначения источника или приемника стрелки вне модели. На диаграммах внешняя ссылка изображается в виде квадрата, рядом с которым показано наименование Внешней ссылки. Внешние ссылки могут быть использованы на диаграммах процессов в любых нотациях. |
||
 | Элемент, обозначающий другую диаграмму. Междиаграммная ссылка служит для обозначения перехода стрелки на диаграмму другого процесса без отображения стрелки на вышележащей диаграмме (при использовании иерархических моделей). В качестве междиаграммной ссылки не может выступать диаграмма процесса в нотациях EPC и BPMN. Междиаграммные ссылки могут быть использованы на диаграммах процессов в нотациях IDEF0, "Процесс", "Процедура". |
|
 | Элемент обозначает ссылку на типовую модель процесса. Наиболее часто повторяющиеся процессы в рамках модели бизнес-процессов могут быть выделены в качестве типовых в отдельную папку в Навигаторе . Диаграмма типового процесса формируется один раз в одном месте Навигатора . Далее на любой диаграмме может быть использован процесс-ссылка на типовой процесс. Параметры типового процесса заполняются непосредственно в Окне свойств типового процесса. Постоянный список субъектов, принимающих участие в выполнении типового процесса, формируется также в Окне свойств типового процесса. Список субъектов, принимающих участие при выполнении типового процесса в рамках вышележащего процесса, формируется в Окне свойств процесса-ссылки на типовой процесс. Процессы-ссылки могут быть использованы на диаграммах процессов в любых нотациях. |
|
 | Выносной элемент, предназначенный для нанесения комментариев. Элемент может быть использован на диаграммах процессов в любых нотациях. |
|
 |
На начальных этапах создания ИС необходимо понять, как работает организация, которую собираются автоматизировать. Никто в организации не знает, как она работает в той мере подробности, которая необходима для создания ИС. Руководитель хорошо знает работу в целом, но не в состоянии вникнуть в детали работы каждого рядового сотрудника. Рядовой сотрудник хорошо знает, что творится на его рабочем месте, но плохо знает, как работают коллеги. Поэтому для описания работы предприятия необходимо построить модель. Такая модель должна быть адекватна предметной области, следовательно, она должна содержать в себе знания всех участников бизнес-процессов организации.
Наиболее удобным языком моделирования бизнес-процессов является IDEF0, предложенный более 20 лет назад Дугласом Россом (SoftTech, Inc.) и называвшийся первоначально SADT - Structured Analysis and Design Technique. (В начале 70-х годов вооруженные силы США применили подмножество SADT, касающееся моделирования процессов, для реализации проектов в рамках программы ICAM (Integrated Computer-Aided Manufacturing). В дальнейшем это подмножество SADT было принято в качестве федерального стандарта США под наименованием IDEF0. Подробные спецификации на стандарты IDEF можно найти на сайте http://www.idef.com .
В IDEF0 система представляется как совокупность взаимодействующих работ или функций. Такая чисто функциональная ориентация является принципиальной - функции системы анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации.
Под моделью в IDEF0 понимают описание системы (текстовое и графическое), которое должно дать ответ на некоторые заранее определенные вопросы.
Моделируемая система рассматривается как произвольное подмножество Вселенной. Произвольное потому, что, во-первых, мы сами умозрительно определяем, будет ли некий объект компонентом системы, или мы будем его рассматривать как внешнее воздействие, и, во-вторых, оно зависит от точки зрения на систему. Система имеет границу, которая отделяет ее от остальной Вселенной. Взаимодействие системы с окружающим миром описывается как вход (нечто, что перерабатывается системой), выход (результат деятельности системы), управление (стратегии и процедуры, под управлением которых производится работа) и механизм (ресурсы, необходимые для проведения работы). Находясь под управлением, система преобразует входы в выходы, используя механизмы.
Процесс моделирования какой-либо системы в IDEF0 начинается с определения контекста, т. е. наиболее абстрактного уровня описания системы в целом. В контекст входит определение субъекта моделирования, цели и точки зрения на модель.
Под субъектом понимается сама система, при этом необходимо точно установить, что входит в систему, а что лежит за ее пределами, другими словами, мы должны определить, что мы будем в дальнейшем рассматривать как компоненты системы, а что как внешнее воздействие. На определение субъекта системы будет существенно влиять позиция, с которой рассматривается система, и цель моделирования - вопросы, на которые построенная модель должна дать ответ. Другими словами, первоначально необходимо определить область (Scope) моделирования. Описание области как системы в целом, так и ее компонентов является основой построения модели. Хотя предполагается, что в течение моделирования область может корректироваться, она должна быть в основном сформулирована изначально, поскольку именно область определяет направление моделирования и когда должна быть закончена модель. При формулировании области необходимо учитывать два компонента - широту и глубину. Широта подразумевает определение границ модели - мы определяем, что будет рассматриваться внутри системы, а что снаружи. Глубина определяет, на каком уровне детализации модель является завершенной. При определении глубины системы необходимо не забывать об ограничениях времени - трудоемкость построения модели растет в геометрической прогрессии от глубины декомпозиции. После определения границ модели предполагается, что новые объекты не должны вноситься в моделируемую систему; поскольку все объекты модели взаимосвязаны, внесение нового объекта может быть не просто арифметической добавкой, но в состоянии изменить существующие взаимосвязи. Внесение таких изменений в готовую модель является, как правило, очень трудоемким процессом (так называемая проблема "плавающей области").
Цель моделирования (Purpose). Модель не может быть построена без четко сформулированной цели. Цель должна отвечать на следующие вопросы:
Почему этот процесс должен быть замоделирован?
Что должна показывать модель?
Что может получить читатель?
Формулировка цели позволяет команде аналитиков сфокусировать усилия в нужном направлении. Примерами формулирования цели могут быть следующие утверждения: "Идентифицировать и определить текущие проблемы, сделать возможным анализ потенциальных улучшений", "Идентифицировать роли и ответственность служащих для написания должностных инструкций", "Описать функциональность предприятия с целью написания спецификаций информационной системы" и т. д.
Точка зрения (Viewpoint) . Хотя при построении модели учитываются мнения различных людей, модель должна строиться с единой точки зрения. Точку зрения можно представить как взгляд человека, который видит систему в нужном для моделирования аспекте. Точка зрения должна соответствовать цели моделирования. Очевидно, что описание работы предприятия с точки зрения финансиста и технолога будет выглядеть совершенно по-разному, поэтому в течение моделирования важно оставаться на выбранной точке зрения. Как правило, выбирается точка зрения человека, ответственного за моделируемую работу в целом. Часто при выборе точки зрения на модель важно задокументировать дополнительные альтернативные точки зрения. Для этой цели обычно используют диаграммы FEO (For Exposition Only).
IDEF0-модель предполагает наличие четко сформулированной цели, единственного субъекта моделирования и одной точки зрения. Для внесения области, цели и точки зрения в модели IDEF0 в BPwin следует выбрать пункт меню Edit/Model Properties , вызывающий диалог Model Properties (рис. 4). В закладкеPurpose следует внести цель и точку зрения, а в закладкуDefinition - определение модели и описание области.
В закладке Status того же диалога можно описать статус модели (черновой вариант, рабочий, окончательный и т. д.), время создания и последнего редактирования (отслеживается в дальнейшем автоматически по системной дате). В закладкеSource описываются источники информации для построения модели (например, "Опрос экспертов предметной области и анализ документации"). ЗакладкаGeneral служит для внесения имени проекта и модели, имени и инициалов автора и временных рамок модели -AS-IS иТО-ВЕ .
Рис. 4. Диалог задания свойств модели
Модели AS-IS и ТО-ВЕ . Обычно сначала строится модель существующей организации работы - AS-IS (как есть). На основе модели AS-IS достигается консенсус между различными единицами бизнеса по тому, "кто что сделал" и что каждая единица бизнеса добавляет в процесс. Модель AS-IS позволяет выяснить, "что мы делаем сегодня" перед тем, как перепрыгнуть на то, "что мы будем делать завтра". Анализ функциональной модели позволяет понять, где находятся наиболее слабые места, в чем будут состоять преимущества новых бизнес-процессов и насколько глубоким изменениям подвергнется существующая структура организации бизнеса. Детализация бизнес-процессов позволяет выявить недостатки организации даже там, где функциональность на первый взгляд кажется очевидной. Признаками неэффективной деятельности могут быть бесполезные, неуправляемые и дублирующиеся работы, неэффективный документооборот (нужный документ не оказывается в нужном месте в нужное время), отсутствие обратных связей по управлению (на проведение работы не оказывает влияния ее результат), входу (объекты или информация используются нерационально) и т. д. Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-ВЕ (как будет) - модели новой организации бизнес-процессов. Модель нужна ТО-ВЕ для анализа альтернативных/лучших путей выполнения работы и документирования того, как компания будет делать бизнес в будущем.
Следует указать на распространенную ошибку при создании модели AS-IS - это создание идеализированной модели. Примером может служить создание модели на основе знаний руководителя, а не конкретного исполнителя работ. Руководитель знаком с тем, как предполагается выполнение работы по руководствам и должностным инструкциям и часто не знает, как на самом деле подчиненные выполняют рутинные работы. В результате получается приукрашенная, искаженная модель, которая несет ложную информацию и которую невозможно в дальнейшем использовать для анализа. Такая модель называется SHOULD_BE (как должно бы быть).
Технология проектирования ИС подразумевает сначала создание модели AS-IS, ее анализ и улучшение бизнес-процессов, т. е. создание модели ТО-ВЕ, и только на основе модели ТО-ВЕ строится модель данных, прототип и затем окончательный вариант ИС. Построение системы на основе модели AS-IS приводит к автоматизации предприятия по принципу "все оставить как есть, только чтобы компьютеры стояли", т. е. ИС автоматизирует несовершенные бизнес-процессы и дублирует, а не заменяет существующий документооборот. В результате внедрение и эксплуатация такой системы приводит лишь к дополнительным издержкам на закупку оборудования, создание программного обеспечения и сопровождение того и другого.
Иногда текущая AS-IS и будущая ТО-ВЕ модели различаются очень сильно, так что переход от начального к конечному состоянию становится неочевидным. В этом случае необходима третья модель, описывающая процесс перехода от начального к конечному состояния системы, поскольку такой переход - это тоже бизнес-процесс.
Результат описания модели можно получить в отчете Model Report . Диалог настройки отчета по модели вызывается из пункта менюReport/Model Report . В диалоге настройки следует выбрать необходимые поля, при этом автоматически отображается очередность вывода информации в отчет (рис. 5).
Рис. 5. Отчет по модели
Диаграммы IDEF0. Основу методологии IDEF0 составляет графический язык описания бизнес-процессов. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Каждая диаграмма является единицей описания системы и располагается на отдельном листе.
Модель может содержать четыре типа диаграмм:
контекстную диаграмму (в каждой модели может быть только одна контекстная диаграмма);
диаграммы декомпозиции;
диаграммы дерева узлов;
диаграммы только для экспозиции (FEO).
Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и ее взаимодействия с внешней средой. После описания системы в целом проводится разбиение ее на крупные фрагменты. Этот процесс называется функциональной декомпозицией, а диаграммы, которые описывают каждый фрагмент и взаимодействие фрагментов, называются диаграммами декомпозиции. После декомпозиции контекстной диаграммы проводится декомпозиция каждого большого фрагмента системы на более мелкие и так далее, до достижения нужного уровня подробности описания. После каждого сеанса декомпозиции проводятся сеансы экспертизы - эксперты предметной области указывают на соответствие реальных бизнес-процессов созданным диаграммам. Найденные несоответствия исправляются, и только после прохождения экспертизы без замечаний можно приступать к следующему сеансу декомпозиции. Так достигается соответствие модели реальным бизнес-процессам на любом и каждом уровне модели. Синтаксис описания системы в целом и каждого ее фрагмента одинаков во всей модели.
Диаграмма дерева узлов показывает иерархическую зависимость работ, но не взаимосвязи между работами. Диаграмм деревьев узлов может быть в модели сколь угодно много, поскольку дерево может быть построено на произвольную глубину и не обязательно с корня.
Диаграммы для экспозиции (FEO) строятся для иллюстрации отдельных фрагментов модели, для иллюстрации альтернативной точки зрения, либо для специальных целей.
Пример создания функционально модели.
В качестве примера рассматривается деятельность вымышленной компании «Computer Word». Компания занимается в основном сборкой и продажей настольных компьютеров и ноутбуков. Компания не производит компоненты самостоятельно, а только собирает и тестирует компьютеры.
Основные виды работ в компании таковы:
продавцы принимают заказы клиентов;
операторы группируют заказы по типам компьютеров;
операторы собирают и тестируют компьютеры;
операторы упаковывают компьютеры согласно заказам;
кладовщик отгружает клиентам заказы.
Компания использует лицензионную бухгалтерскую информационную систему, которая позволяет оформить заказ, счет и отследить платежи по счетам.
Методика выполнения работы
1. Запустите BPwin ().
2. Если появляется диалог ModelMart Connection Manager , нажмите на кнопкуCancel (Отмена).
3. Щелкните по кнопке . Появляется диалоговое окноI would like to (рис. 6). Внесите в текстовое полеName имя модели "Деятельность компании" и выберите Туре –Business Process (IDEF0) . Нажмите кнопкуОК .
Рис. 6. Присвоение модели имени и выбор типа модели
4. Откроется диалоговое окно Properties for New Models (Свойства новой модели) (рис. 7). Введите в текстовое полеAuthor (Автор) имя автора модели и в текстовое полеAuthor initials его инициалы. Нажмите последовательно кнопкиApply иОК .
5. Автоматически создается незаполненная контекстная диаграмма (рис. 8).
6. Обратите внимание на кнопку на панели инструментов. Эта кнопка включает и выключает инструмент просмотра и навигации -Model Explorer (Браузер модели).Model Explorer имеет три вкладки –Activities (), Diagrams () и Objects (). Во вкладкеActivities щелчок правой кнопкой по объекту в браузере модели позволяет выбрать опции редактирования его свойств (рис. 9).
Рис. 8. Незаполненная контекстная диаграмма
Рис. 9. Щелчок правой кнопкой по объекту во вкладке Activities позволяет воспользоваться контекстным меню для редактирования его свойств
7. Перейдите в меню Model/Model Properties . Во вкладкеGeneral диалогового окнаModel Properties в текстовое полеModel name следует внести имя модели "Деятельность компании", а в текстовое полеProject имя проекта "Модель деятельности компании", и, наконец, в текстовоеTime Frame (Временной охват) -AS-IS (Как есть) (рис. 10).
Рис. 10. Окно задания свойств модели
8. Во вкладке Purpose диалогового окнаModel Properties в текстовое полеPurpose (цель) внесите данные о цели разработки модели - "Моделировать текущие (AS-IS) бизнес-процессы компании", а в текстовое полеViewpoint (точка зрения) - "Директор" (рис. 11).
Рис. 11. Внесение данных о цели моделирования и точке зрения
9. Во вкладке Definition диалогового окнаModel Properties в текстовое полеDefinition (Определение) внесите "Это учебная модель, описывающая деятельность компании" и в текстовое полеScope (охват) - "Общее управление бизнесом компании: исследование рынка, закупка компонентов, сборка, тестирование и продажа продуктов" (рис. 12).
10. Перейдите на контекстную диаграмму и правой кнопкой мыши щелкните по прямоугольнику представляющему, в нотации IDEF0 , условное графическое обозначение работы. В контекстном меню выберите опциюName (рис. 13). Во вкладкеName внесите имя "Деятельность компании" (рис. 14).
11. Во вкладке Definition диалогового окнаActivity Properties в текстовое полеDefinition (Определение) внесите "Текущие бизнес-процессы компании" (рис. 15). Текстовое полеNote (Примечания) оставьте незаполненным.
Рис. 12. Внесение дополнительных данных определяющих модель
Рис. 13. Контекстное меню для работы с выбранной опцией Name
Рис. 14. Присвоение работе названия
Рис. 15. Внесение дополнительных данных о работе
12. Создайте ICOM -стрелки на контекстной диаграмме (таблица 1).
Таблица 1 - Стрелки контекстной диаграммы
|
Название стрелки (Arrow Name ) |
Определение стрелки (Arrow Definition ) |
Тип стрелки (Arrow Type ) |
|
Звонки клиентов |
Запросы информации, заказы, техподдержка и т.д. | |
|
Правила и процедуры |
Правила продаж, инструкции по сборке, процедуры тестирования, критерии производительности и т. д. | |
|
Проданные продукты |
Настольные и портативные компьютеры | |
|
Бухгалтерская система |
Оформление счетов, оплата счетов, работа с заказами |
13. С помощью кнопки внесите текст в поле диаграммы - точку зрения и цель (рис. 16).
Рис. 16. Внесение текста в поле диаграммы с помощью редактора Text Block Editor
14. Создайте отчет по модели. В меню Tools/Reports/Model Report (рис. 17) задайте опции генерирования отчета (установите галочки) и нажмите кнопкуPreview (Предварительный просмотр) (рис. 18).
Рис. 17. Задание опций генерирования отчета Model Report
Рис. 18. Предварительный просмотр отчета Model Report
Декомпозиция производственных процессов по методологии IDEF 0
Работы (Activity)
Работы обозначают поименованные процессы, функции или задачи, которые происходят в течение определенного времени и имеют распознаваемые результаты. Работы изображаются в виде прямоугольников. Все работы должны быть названы и определены. Имя работы должно быть выражено отглагольным существительным, обозначающим действие (например, "Изготовление детали", "Прием заказа" и т.д.). Работа "Изготовление детали" может иметь, например, следующее определение: "Работа относится к полному циклу изготовления изделия от контроля качества сырья до отгрузки готового упакованного изделия". При создании новой модели (меню File/New ) автоматически создается контекстная диаграмма с единственной работой, изображающей систему в целом (рис. 1).
Для внесения имени работы следует щелкнуть по работе правой кнопкой мыши, выбрать в меню Name Editor и в появившемся диалоге внести имя работы. Для описания других свойств работы служит диалогActivity Properties (рис. 2).
Рис. 1. Пример контекстной диаграммы
Рис. 2. Редактор задания свойств работы
Диаграммы декомпозиции содержат родственные работы, т.е. дочерние работы, имеющие общую родительскую работу. Для создания диаграммы декомпозиции следует щелкнуть по кнопке .
Возникает диалог Activity Box Count (рис. 3), в котором следует указать нотацию новой диаграммы и количество работ на ней. Выберем нотациюIDEF0 и щелкнем наОК . Появляется диаграмма декомпозиции (рис. 4). Допустимый интервал числа работ 2-8. Декомпозировать работу на одну работу не имеет смысла: диаграммы с количеством работ более восьми получаются перенасыщенными и плохо читаются. Для обеспечения наглядности и лучшего понимания моделируемых процессов рекомендуется использовать от трех до шести блоков на одной диаграмме.
Рис . 3. Диалог Activity Box Count
Рис. 4. Пример диаграммы декомпозиции
Если оказывается, что количество работ недостаточно, то работу можно добавить в диаграмму, щелкнув сначала по кнопке на палитре инструментов, а затем по свободному месту на диаграмме.
Работы на диаграммах декомпозиции обычно располагаются по диагонали от левого верхнего угла к правому нижнему.
Такой порядок называется порядком доминирования. Согласно этому принципу расположения в левом верхнем углу располагается самая важная работа или работа, выполняемая по времени первой. Далее вправо вниз располагаются менее важные или выполняемые позже работы. Такое расположение облегчает чтение диаграмм, кроме того, на нем основывается понятие взаимосвязей работ.
Каждая из работ на диаграмме декомпозиции может быть в свою очередь декомпозирована. На диаграмме декомпозиции работы нумеруются автоматически слева направо. Номер работы показывается в правом нижнем углу. В левом верхнем углу изображается небольшая диагональная черта, которая показывает, что данная работа не была декомпозирована. Так, например, работа "Сборка изделия" имеет номер 3 и не была еще декомпозирована. Работа "Контроль качества" (номер 4) имеет нижний уровень декомпозиции
Стрелки (Arrow)
Взаимодействие работ с внешним миром и между собой описывается в виде стрелок. Стрелки представляют собой некую информацию и именуются существительными (например, "Заготовка", "Изделие", "Заказ").
В IDEF0 различают пять типов стрелок:
Вход (Input) - материал или информация, которые используются или преобразуется работой для получения результата (выхода). Допускается, что работа может не иметь ни одной стрелки входа. Каждый тип стрелок подходит к определенной стороне прямоугольника, изображающего работу, или выходит из нее. Стрелка входа рисуется как входящая в левую грань работы. При описании технологических процессов (для этого и был придуман IDEF0) не возникает проблем определения входов. Действительно, "Сырье" на рис. 1. - это нечто, что перерабатывается в процессе "Изготовление изделия" для получения результата. При моделировании ИС, когда стрелками являются не физические объекты, а данные, не все так очевидно. Например, при "Приеме пациента" карта пациента может быть и на входе и на выходе, между тем качество этих данных меняется. Другими словами, в этом примере для того, чтобы оправдать свое назначение, стрелки входа и выхода должны быть точно определены с тем, чтобы указать на то, что данные действительно были переработаны (например, на выходе - "Заполненная карта пациента"). Очень часто сложно определить, являются ли данные входом или управлением. В этом случае подсказкой может служить то, перерабатываются/изменяются ли данные в работе или нет. Если изменяются, то скорее всего это вход, если нет - управление.
Управление (Control) - правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления. Стрелка управления рисуется как входящая в верхнюю грань работы. На рис. 1 стрелки "Задание"и "Чертеж" - управление для работы "Изготовление изделия". Управление влияет на работу, но не преобразуется работой. Если цель работы - изменить процедуру или стратегию, то такая процедура или стратегия будет для работы входом. В случае возникновения неопределенности в статусе стрелки (управление или вход) рекомендуется рисовать стрелку управления.
Выход (Output) - материал или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться. Стрелка выхода рисуется как исходящая из правой грани работы. На рис. 1 стрелка "Готовое изделие" является выходом для работы "Изготовление изделия".
Механизм (Mechanism) - ресурсы, которые выполняют работу, например персонал предприятия, станки, устройства и т. д. Стрелка механизма рисуется как входящая в нижнюю грань работы. На рис. 1 стрелка "Персонал предприятия" является механизмом для работы "Изготовление изделия". По усмотрению аналитика стрелки механизма могут не изображаться в модели.
Вызов (Call) - специальная стрелка, указывающая на другую модель работы. Стрелка вызова рисуется как исходящая из нижней грани работы. На рис. 1 стрелка "Другая модель работы" является вызовом для работы "Изготовление изделия". Стрелка вызова используется для указания того, что некоторая работа выполняется за пределами моделируемой системы. В BPwin стрелки вызова используются в механизме слияния и разделения моделей.
Граничные стрелки. Стрелки на контекстной диаграмме служат для описания взаимодействия системы с окружающим миром. Они могут начинаться у границы диаграммы и заканчиваться у работы, или наоборот. Такие стрелки называются граничными.
Для внесения граничной стрелки входа следует:
Стрелки управления, выхода, механизма и выхода изображаются аналогично. Для рисования стрелки выхода, например, следует щелкнуть по кнопке с символом стрелки в палитре инструментов, щелкнуть в правой части работы со стороны выхода (где начинается стрелка), перенести курсор к правой стороне экрана, пока не появится начальная штриховая полоска, и щелкнуть один раз по штриховой полоске.
Имена вновь внесенных стрелок автоматически заносятся в словарь (Arrow Dictionary ).
ICOM-коды. Диаграмма декомпозиции предназначена для детализации работы. В отличие от моделей, отображающих структуру организации, работа на диаграмме верхнего уровня в IDEF0 - это не элемент управления нижестоящими работами. Работы нижнего уровня - это то же самое, что работы верхнего уровня, но в более детальном изложении. Как следствие этого границы работы верхнего уровня - это то же самое, что границы диаграммы декомпозиции.ICOM (аббревиатура отInput, Control, Output и Mechanism ) - коды, предназначенные для идентификации граничных стрелок. КодICOM содержит префикс, соответствующий типу стрелки (I ,С ,О илиМ ), и порядковый номер. BPwin вносит ICOM-коды автоматически. Для отображения ICOM-кодов следует включить опциюShow ICOM codes на закладке Presentation диалога Model Properties .
Словарь стрелок редактируется при помощи специального редактора Arrow Dictionary Editor , в котором определяется стрелка и вносится относящийся к ней комментарий (рис. 6). Словарь стрелок решает очень важную задачу. Диаграммы создаются аналитиком для того, чтобы провести сеанс экспертизы, т. е. обсудить диаграмму со специалистом предметной области. В любой предметной области формируется профессиональный жаргон, причем очень часто жаргонные выражения имеют нечеткий смысл и воспринимаются разными специалистами по-разному. В то же время аналитик - автор диаграмм должен употреблять те выражения, которые наиболее понятны экспертам. Поскольку формальные определения часто сложны для восприятия, аналитик вынужден употреблять профессиональный жаргон, а, чтобы не возникло неоднозначных трактовок, в словаре стрелок каждому понятию можно дать расширенное и, если это необходимо, формальное определение.
Содержимое словаря стрелок можно распечатать в виде отчета (меню Report/Arrow Report... ) и получить тем самым толковый словарь терминов предметной области, использующихся в модели.
Рис . 5. Диалог Arrow Properties
Рис. 6. Словарь стрелок
Несвязанные граничные стрелки (unconnected border arrow). При декомпозиции работы входящие в нее и исходящие из нее стрелки (кроме стрелки вызова) автоматически появляются на диаграмме декомпозиции (миграция стрелок), но при этом не касаются работ. Такие стрелки называются несвязанными и воспринимаются в BPwin как синтаксическая ошибка. Для связывания стрелок входа, управления или механизма необходимо перейти в режим редактирования стрелок, щелкнуть по наконечнику стрелки и щелкнуть по соответствующему сегменту работы. Для связывания стрелки выхода необходимо перейти в режим редактирования стрелок, щелкнуть по сегменту выхода работы и затем по стрелке.
Внутренние стрелки. Для связи работ между собой используются внутренние стрелки, т. е. стрелки, которые не касаются границы диаграммы, начинаются у одной и кончаются у другой работы.
Для рисования внутренней стрелки необходимо в режиме рисования стрелок щелкнуть по сегменту (например, выхода) одной работы и затем по сегменту (например, входа) другой. В IDEF0 различают пять типов связей работ.
Связь по входу (output-input) , когда стрелка выхода вышестоящей работы (далее - просто выход) направляется на вход нижестоящей.
Связь по управлению (output-control) , когда выход вышестоящей работы направляется на управление нижестоящей. Связь по управлению показывает доминирование вышестоящей работы. Данные или объекты выхода вышестоящей работы не меняются в нижестоящей.
Обратная связь по входу (output-input feedback) , когда выход нижестоящей работы направляется на вход вышестоящей. Такая связь, как правило, используется для описания циклов.
Обратная связь по управлению (output-control feedback) , когда выход нижестоящей работы направляется на управление вышестоящей. Обратная связь по управлению часто свидетельствует об эффективности бизнес - процесса.
Связь выход-механизм (output-mechanism) , когда выход одной работы направляется на механизм другой. Эта взаимосвязь используется реже остальных и показывает, что одна работа подготавливает ресурсы, необходимые для проведения другой работы.
Явные стрелки . Явная стрелка имеет источником одну-единственную работу и назначением тоже одну-единственную работу.
Разветвляющиеся и сливающиеся стрелки . Одни и те же данные или объекты, порожденные одной работой, могут использоваться сразу в нескольких других работах. С другой стороны, стрелки, порожденные в разных работах, могут представлять собой одинаковые или однородные данные или объекты, которые в дальнейшем используются или перерабатываются в одном месте. Для моделирования таких ситуаций в IDEF0 используются разветвляющиеся и сливающиеся стрелки. Для разветвления стрелки нужно в режиме редактирования стрелки щелкнуть по фрагменту стрелки и по соответствующему сегменту работы. Для слияния двух стрелок выхода нужно в режиме редактирования стрелки сначала щелкнуть по сегменту выхода работы, а затем по соответствующему фрагменту стрелки.
Смысл разветвляющихся и сливающихся стрелок передается именованием каждой ветви стрелок. Существуют определенные правила именования таких стрелок. Рассмотрим их на примере разветвляющихся стрелок. Если стрелка именована до разветвления, а после разветвления ни одна из ветвей не именована, то подразумевается, что каждая ветвь моделирует те же данные или объекты, что и ветвь до разветвления.
Если стрелка именована до разветвления, а после разветвления какая-либо из ветвей не именована, то подразумевается, что эти ветви соответствуют именованию. Если при этом какая-либо ветвь после разветвления осталась неименованной, то подразумевается, что она моделирует те же данные или объекты, что и ветвь до разветвления.
Недопустима ситуация, когда стрелка до разветвления не именована, а после разветвления не именована какая-либо из ветвей. BPwin определяет такую стрелку как синтаксическую ошибку.
Правила именования сливающихся стрелок полностью аналогичны - ошибкой будет считаться стрелка, которая после слияния не именована, а до слияния не именована какая-либо из ее ветвей. Для именования отдельной ветви разветвляющихся и сливающихся стрелок следует выделить на диаграмме только одну ветвь, после этого вызвать редактор имени и присвоить имя стрелке. Это имя будет соответствовать только выделенной ветви.
Тоннелирование стрелок . Вновь внесенные граничные стрелки на диаграмме декомпозиции нижнего уровня изображаются в квадратных скобках и автоматически не появляются на диаграмме верхнего уровня.
Для их "перетаскивания" наверх нужно сначала выбрать кнопку на палитре инструментов и щелкнуть по квадратным скобкам граничной стрелки. Появляется диалог Border Arrow Editor (рис. 7).
Рис . 7. Диалог Border Arrow Editor
Если щелкнуть по кнопке Resolve Border Arrow , стрелка мигрирует на диаграмму верхнего уровня, если по кнопкеChangeToTunnel- стрелка будет затоннелирована и не попадет на другую диаграмму.
Тоннелирование может быть применено для изображения малозначимых стрелок. Если на какой-либо диаграмме нижнего уровня необходимо изобразить малозначимые данные или объекты, которые не обрабатываются или не используются работами на текущем уровне, то их необходимо направить на вышестоящий уровень (на родительскую диаграмму). Если эти данные не используются на родительской диаграмме, их нужно направить еще выше, и т. д. В результате малозначимая стрелка будет изображена на всех уровнях и затруднит чтение всех диаграмм, на которых она присутствует. Выходом является тоннелирование стрелки на самом нижнем уровне. Такое тоннелирование называется "не-в-родительской-диаграмме".
Пример создания диаграммы декомпозиции
1. Выберите кнопку перехода на нижний уровень в палитре инструментов и в диалоговом окнеActivity Box Count (рис. 8) установите число работ на диаграмме нижнего уровня - 3 - и нажмите кнопкуОК .
Рис. 8. Диалоговое окно Activity Box Count
2. Автоматически будет создана диаграмма декомпозиции (рис. 9).
Рис. 9. Диаграмма декомпозиции
Правой кнопкой мыши щелкните по работе расположенной в левом верхнем углу области редактирования модели, выберите в контекстном меню опцию Name и внесите имя работы. Повторите операцию для оставшихся двух работ. Затем внесите определение, статус и источник для каждой работы согласно данным таблицы 1.
Таблица 1. Работы диаграммы декомпозиции А0
Диаграмма декомпозиции примет вид представленный на рис. 10.
Рис.10 Диаграмма декомпозиции после присвоения работам наименований
3. Для изменения свойств работ после их внесения в диаграмму можно воспользоваться словарем работ (рис. 11). Вызов словаря производится при помощи пункта главного меню Dictionary /Activity .
Рис . 11. Словарь Activity Dictionary
Если описать имя и свойства работы в словаре, ее можно будет внести в диаграмму позже с помощью кнопки в палитре инструментов. Невозможно удалить работу из словаря, если она используется на какой-либо диаграмме. Если работа удаляется из диаграммы, из словаря она не удаляется. Имя и описание такой работы может быть использовано в дальнейшем. Для добавления работы в словарь необходимо перейти в конец списка и щелкнуть правой кнопкой по последней строке. Возникает новая строка, в которой нужно внести имя и свойства работы. Для удаления всех имен работ, не использующихся в модели, щелкните по кнопке(Purge (Чистить)).
4. Перейдите в режим рисования стрелок и свяжите граничные стрелки, воспользовавшись кнопкой на палитре инструментов так, как это показано на рис. 12.
Рис. 12. Связанные граничные стрелки на диаграмме А0
5. Правой кнопкой мыши щелкните по ветви стрелки управления работы "Сборка и тестирование компьютеров" и переименуйте ее в "Правила сборки и тестирования" (рис. 13). Внесите определение для новой ветви: "Инструкции по сборке, процедуры тестирования, критерии производительности и т. д.". Правой кнопкой мыши щелкните по ветви стрелки механизма работы "Продажи и маркетинг" и переименуйте ее как "Система оформления заказов" (рис. 14).
Рис. 13. Стрелка "Правила сборки и тестирования"
Рис. 14. Стрелка "Система оформления заказов"
6. Альтернативный метод внесения имен и свойств стрелок - использование словаря стрелок (вызов словаря - меню Dictionary/ Arrow ). Если внести имя и свойства стрелки в словарь (рис. 15), ее можно будет внести в диаграмму позже.
Рис. 15. Словарь стрелок
Стрелку нельзя удалить из словаря, если она используется на какой-либо диаграмме. Если удалить стрелку из диаграммы, из словаря она не удаляется. Имя и описание такой стрелки может быть использовано в дальнейшем. Для добавления стрелки необходимо перейти в конец списка и щелкнуть правой кнопкой по последней строке. Возникает новая строка, в которой нужно внести имя и свойства стрелки.
7. Создайте новые внутренние стрелки так, как показано на рис. 16.
Рис. 16. Внутренние стрелки диаграммы А0
8. Создайте стрелку обратной связи (по управлению) "Результаты сборки и тестирования", идущую от работы "Сборка и тестирование компьютеров" к работе "Продажи и маркетинг". Измените, при необходимости, стиль стрелки (толщина линий) и установите опцию Extra Arrowhead (Дополнительный Наконечник стрелы) (из контекстного меню). Методомdrag&drop перенесите имена стрелок так, чтобы их было удобнее читать. Если необходимо, установите из контекстного менюSquiggle (Загогулину). Результат возможных изменений показан на рис. 17.
Рис. 17. Результат редактирования стрелок на диаграмме А0
9. Создайте новую граничную стрелку выхода "Маркетинговые материалы", выходящую из работы "Продажи и маркетинг". Эта стрелка автоматически не попадает на диаграмму верхнего уровня и имеет квадратные скобки на наконечнике (рис. 18).
Рис. 18. Стрелка Маркетинговые материалы
10. Щелкните правой кнопкой мыши по квадратным скобкам и выберите пункт меню Arrow Tunnel (рис. 19).
В диалоговом окне Border Arrow Editor (Редактор Граничных Стрелок) выберите опциюResolve it to Border Arrow (Разрешить как Граничную Стрелку) (рис. 20).
Рис . 19. Пункт меню Arrow Tunnel
Рис . 20. Диалоговое окно Border Arrow Editor
Для стрелки "Маркетинговые материалы" выберите опцию Trim (Упорядочить) из контекстного меню. Результат выполнения лабораторной работы показан на рис. 21.
Рис. 21. Результат выполнения декомпозиции
Одна картинка стоит тысячи слов
Народная мудрость
Конечно, в теории функциональная модель работы компании должна быть у руководителя, причем, неважно, идет речь об организации работы склада или об IT системе (от лида до заявки). Но в реальности практически никогда ее не оказывается, а потому в процессе изучения и поиска решения поставленной клиентом задачи я также создаю функциональную модель работы компании или определенного процесса (функции) самостоятельно.
Несколько слов о преимуществах графики
Как известно, функциональные модели IDEF0 - это всегда графические схемы. У них есть свои особенности и правила составления. Об этом мы поговорим чуть-чуть позже. А сейчас я хотел бы привести пару примеров эффективности графики. Почему я делаю на этом акцент? Скорей всего, после моего утверждения о необходимости функциональной модели работы компании, очень многие подумали, что это все необязательно, можно и на словах пояснить как работает та или иная функция в компании. Вот об этом я и хочу поговорить.
И для начала сделаем небольшой экскурс в историю. Вернемся в далекий 1877 год, в период Русско-Турецкой войны. Именно тогда полиграфист Сытин впервые применил графику при описании военных действий. Сейчас для нас все это привычно, при описании любого сражения у каждого перед глазами возникают карты со стрелками, которые наглядно показывают ход сражения. А в те времена военные действия описывались словами. Для каждого боя - много-много слов. И понять в итоге, что же происходит, было очень сложно.
А потому идея Сытина была поистине революционной - он начал печатать литографические копии карт с обозначением укреплений и расположений воинских частей. Назывались эти карты “Для читателей газет. Пособие”. Идея оказалась настолько актуальной, что первый же тираж “Пособий” разошелся мгновенно. И потом такие приложения были очень востребованы. Причина очевидна. Графика помогала понять то, что при помощи одних слов разобрать было практически невозможно.
Аналогичный пример беспомощности словесных описаний я могу привести также из своей практики. Один из моих заказчиков очень просил взяться за внедрение ERM-системы для его компании. На вопрос, есть ли у них какое-то техническое задание, я получил ответ: “Да, есть. Но в нем 400 страниц”. При этом клиент очень жаловался, что мои коллеги, к которым он обращался ранее, либо отказывались от проекта вообще, либо называли явно завышенные цены. После того, как я увидел, что в техническом задании действительно 400 страниц, и состоит оно исключительно из текстового описания, я понял причины поведения разработчиков. Прочитать такой объем текста, вникнуть в него, разобраться во всех нюансах только для того, чтобы понять задачу и назвать цену - это и правда очень сложно.
Этому клиенту я предложил альтернативный вариант - описать все, что можно, графически в виде нотаций. Показал ему примеры моделирования. В итоге они сейчас переосмысливают свои пожелания и оформление технического задания.
Знаю я также много других примеров, когда графическое моделирование бизнес-процессов помогало в работе как моим коллегам, бизнес-консультантам и разработчикам, так и самим бизнесменам
Почему это важно для моей работы
Моя работа всегда связана с внесением изменений в существующую систему. А для того, чтобы внести изменения и получить нужный результат, нужно изучить то, что существует уже сейчас. И не важно, что именно мы делаем – настраиваем или устанавливаем с нуля CRM-систему, создаем эффективную ERP-систему, занимаемся интеграцией различных систем для повышения автоматизации работы в целом. В любом случае, для начала, необходимо получить представление о существующей схеме работы, и только после этого можно предлагать какие-то изменения и продумывать варианты решения поставленной задачи.
После изучения существующего положения вещей я, как и любой другой сторонний специалист, создаю коммерческое предложение, в котором максимально подробно раскрываю мое видение текущей ситуации, а также действия, которые необходимо выполнить для решения поставленной задачи, и, конечно, ожидаемый результат.
Такие отчеты об обследовании работы получаются объемные, занимают не одну страницу, что с одной стороны, необходимо, а с другой – усложняет восприятие. Вначале я, как и многие, думал, что объемные отчеты - это хорошо, ведь человек платит за работу и нужно ему предоставить максимум подробной информации.
На самом деле, важно не предоставить объем, а максимально быстро и полно донести суть. Большие объемы текста требуют времени, которого у бизнесменов чаще всего очень мало. А графика позволяет сократить объем моего предложения и наглядно, в понятной форме показать решение. В результате мои предложения значительно сократились, в них появилась графика, а решения о начале сотрудничества стали приниматься быстрее.
Именно по этой причине я использую наглядные модели. Как известно, одна картинка стоит тысячи слов. И в случае описания бизнес-процессов и вариантов модернизации работы бизнеса – это действительно так. И здесь очень хорошо подходят нотации IDEF0.
Но для начала, давайте разберемся с основными понятиями, что такое нотации, зачем они нужны, что такое IDEF0, в чем особенности и преимущества этого метода
Что такое нотация описания бизнес-процессов
Нотацией называется формат описания бизнес-процесса, представляющий собой совокупность графических объектов, используемых при моделировании, а также правил моделирования.
По сути, нотации – это особый графический язык, который позволяет описывать работу компании, наглядно демонстрировать взаимодействие между различными подразделениями, т.е. описывать бизнес-процессы. Нотации могут применяться для процессного или функционального моделирования.
В общем, нотации можно назвать языком программирования при бизнес-анализе
Что такое IDEF0?
IDEF0 - методология функционального моделирования (англ. function modeling) и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является ее акцент на соподчиненность объектов. В IDEF0 рассматриваются логические отношения между работами, а не их временнаL9;я последовательность (поток работ). Википедия
Стандарт IDEF0 был разработан в 1981 году в США департаментом Военно-воздушных сил для автоматизации промышленных предприятий. В процессе разработки программного обеспечения разработчики столкнулись с необходимостью разработки новых методов анализа бизнес-процессов. В результате появилась методология функционального моделирования IDEF0, в которой для анализа применяются специальные нотации IDEF0.
Функциональная модель компании
Функциональная модель IDEF0 представляет собой набор блоков, каждый из которых представляет собой «черный ящик» со входами и выходами, управлением и механизмами, которые детализируются (декомпозируются) до необходимого уровня. Наиболее важная функция расположена в верхнем левом углу. А соединяются функции между собой при помощи стрелок и описаний функциональных блоков. При этом каждый вид стрелки или активности имеет собственное значение. Данная модель позволяет описать все основные виды процессов, как административные, так и организационные.
Стрелки могут быть:
- Входящие – вводные, которые ставят определенную задачу.
- Исходящие – выводящие результат деятельности.
- Управляющие (сверху вниз) – механизмы управления (положения, инструкции и пр).
- Механизмы (снизу вверх) – что используется для того, чтобы произвести необходимую работу.
Входящие и исходящие стрелки точнее было бы называть вводящими и выводящими, так как по-английски они называются Input и Output соответственно. Но особенности перевода и привычные названия выглядят уже так, как сложилось. И все же для правильного понимания терминов важно помнить их значение в данном случае. Это подтверждается еще и тем, что данная нотация создана прежде всего для разработки ПО, и термины переводить правильнее в этой точки зрения.
Стрелки подписываются при помощи имен существительных (опыт, план, правила), а блоки – при помощи глаголов, т.е. в них описываются действия, которые производятся (создать товар, заключить договор, произвести отгрузку).
IDEF0 – это очень простой и одновременно наглядный язык описания бизнес-процессов. С помощью этого стандарта возможна передача информации между разработчиками, консультантами и пользователями. Стандарт очень тщательно разрабатывался, он удобен для проектирования, универсален. Для работы с ним существует множество инструментов, например, VISIO, BPWIN, ERWIN, Bussines studio и т.д.
Кроме того, использование для создания бизнес-моделей IDEF0 - это не только удобно, это еще и правильно. Этот инструмент был разработан для бизнес-аналитики, он прошел длительную и тщательную отладку и шлифовку. А потому при помощи IDEF0 создать функциональную модель без ошибок намного проще, чем без применения этого стандарта.
Как известно, забивать гвозди лучше всего молотком. Конечно, вы можете для этого применять и другие инструменты, но молоток - наиболее функционален и с его помощью проще всего забить гвоздь аккуратно и точно. Так и с применением IDEF0 - этот инструмент был создан для функционального моделирования, и с его помощью вы намного быстрее и точнее сможете получить нужный результат.
Пример создания функциональной модели IDEF0
Для того чтобы понять, как работать с функциональным моделированием, я приведу пример процесса написания статьи.
Основной блок – «Написать статью».
Входящие стрелки – «Опыт», «Информация из сторонних источников». Это те вводные, которые необходимы для начала работы.
Управляющие для написания статьи – это «План публикации», «Требования издателя», «Правила русского языка».
А в роли «Механизмов» выступают автор, копирайтер, корректор и программное обеспечение. В данном случае автор создает аудиоматериал, в котором собирает все мысли и идеи, которые должны быть отражены в статье. Копирайтер – это человек, который создает на основе этого материала, руководствуясь требованиями издателя, планом публикации и правилами русского языка, готовый текст статьи. Корректор проверяет материал на ошибки. А программное обеспечение – это те инструменты, которые используют в работе все участники процесса.
Таким образом, я задал основные параметры процесса, его вход, выход, а также все необходимое для успешного проведения процесса. Но это – только основные рамки процесса. Так описывается общая схема работы компании в целом.
На самом деле, процесс создания статьи, как и любой бизнес-процесс можно и нужно детализировать. Для этого я декомпозирую общий блок «написать статью» на связанные между собой элементы.
В нашем случае работа делится на 4 основных этапа:
- Подготовить аудио.
- Подготовить текст
- Подготовить текст к публикации.
- Разместить статью в издании.
На схеме наглядно видно, на каком этапе какие управляющие элементы и какие механизмы задействованы.
Так, автор при создании аудио использует свои знания и опыт, при этом руководствуется планом публикации и требованиями издателя. Копирайтер получает на входе аудиозапись, из которой, руководствуясь правилами русского языка, создает текст. Корректор получает текст и проверяет его, также руководствуясь правилами русского языка. Для размещения статьи в издании необходимо специальное программное обеспечение.
При создании функциональной модели ключевыми параметрами являются цель и точка зрения. Исходя из них, моделирование одних и тех же процессов может выглядеть несколько по-разному. Например, в моем случае целью является «рассказать о процессе написания статьи». А точка зрения копирайтера – это «написание и публикация статьи с точки зрения руководителя процесса».
Так, если бы тот же процесс был описан с точки зрения копирайтера, то входящими были бы опыт и аудиофайл от автора. При этом в таком случае под Опытом подразумевался бы опыт копирайтера, но не руководителя или автора. А потому первое, что нужно определить при создании модели бизнес-процесса – это выбрать точку зрения и четко сформулировать цель.
Такое моделирование не только наглядно, но и очень удобно для принятия эффективных управленческих решений. Например, в описанном выше бизнес-процессе есть два отдельных специалиста - копирайтер и корректор. Если я поставлю задачу оптимизировать финансирование проекта, то я благодаря схеме сразу увижу, где это и как можно сделать. Так, к копирайтер и корректор пользуются примерно одинаковыми правилами, но копирайтер получает аудио, а выдает результат в виде текста, корректор же и принимает, и отдает текст. А потому при необходимости я могу, скажем, за половину стоимости обязанности корректора предложить копирайтеру. Так я сэкономлю средства и время на взаимодействие разных специалистов. Конечно, я понимаю все заслуги корректоров и почему лучше работать с отдельным специалистам. Но напоминаю - у меня стоит задача: оптимизация затрат.
Без такого наглядного инструмента было бы сложнее определить, какие из блоков можно удалить и, таким образом, оптимизировать работу.
Как создавать нотации IDEF0
Существует множество различных программных продуктов, которые можно применять при создании нотаций. Какие-то созданы специально для функционального моделирования, другие предназначены для любой работы с графическими элементами. Где и как вы будете строить эти модели – решать вам.
Я лично считаю, что на первом этапе нет ничего лучше, чем обычная бумага, простой карандаш и ластик, чтобы вносить корректировки в случае ошибок.
Для того чтобы создать нотацию существующих бизнес-процессов, т.е. описать, как сейчас работает компания, необходимо принципы работы изучить. Сторонний специалист (консультант, разработчик) для этого проводит интервью. На первом этапе на вопросы отвечает руководитель компании, далее в процессе детализации нотации проводятся интервью сотрудников, отвечающих за различные этапы работы.
При этом важно понимать, что в результате потребуется 2 нотации. Первая будет отображать бизнес-процессы в виде «как есть». Ее вы создаете на основе интервью и согласовываете каждую детализацию с сотрудниками компании и руководителем. Очень важно, чтобы ваше видение существующих процессов совпало с реальностью, именно для этого и требуется подтверждение на всех уровнях.
Вторая нотация – «как должно быть». Она создается на основе первой и тех изменений, которые вы предлагаете внести в структуру работы для оптимизации и автоматизации работы компании в рамках выполнения поставленной задачи.
Требования стандарта IDEF0
Базовые требования стандарта IDEF0, в принципе, я описал выше и показал на примере.
- В левом верхнем углу всегда – главный элемент.
- Все элементы должны иметь входящие и исходящие стрелки, так как для выполнения необходимо что-то получить на входе (заказ, поставленную задачу), а после обработки на выходе необходимо передать готовый продукт. Входящие стрелки всегда слева, исходящие – справа.
- Сверху – управляющие элементы, снизу – механизмы, необходимые для выполнения процесса.
- Если на одном листе (экране) располагается несколько блоков, каждый последующий располагается справа и ниже предыдущего.
- Необходимо стремиться создавать схемы таким образом, чтобы пересечение стрелок было сведено к необходимому минимуму.
Типичные ошибки
Функциональное моделирование выполняют при помощи самых разных инструментов, в том числе, не предназначенных для моделирования. В последнем случае нет проверки на ошибки и ограничения стандарта. Желание повысить наглядность и отсутствие опыта при этом часто оканчиваются ошибками.
Использование различных цветов
Все элементы на диаграмме одинаково важны. При функциональном моделировании нет более или менее важных элементов. Исчезновение любого приведет к нарушению процесса и производственному браку.
Часто при моделировании на бумаге или в различных программах пользователи пытаются повысить наглядность за счет использования разных цветов. Это одна из самых распространенных ошибок. На самом деле, применение разноцветных стрелок и блоков только вносит дополнительную путаницу, а также искажает восприятие схемы.
Ваша модель должна читаться в черно-белом виде, без каких-то дополнительных цветовых решений. Такой подход одновременно помогает избежать недоразумений и дисциплинирует создателя модели, в результате читабельность и грамотность модели повышаются.
Слишком большое количество блоков
При составлении модели часто стараются отобразить на одном листе все нюансы работы компании со всеми подробностями. В результате получается очень большое количество блоков с большим количеством управляющих стрелок. Читабельность при этом теряется.
Оптимальный вариант – это детализация, достаточная для понимания вопроса, и не более того. Подробная детализация работы каждого подразделения или даже сотрудника может раскрываться при выборе подробного просмотра того или иного процесса. И создается такая структура только если это действительно нужно для работы или принятия решения.
Нарушение структуры при внесении корректировок
Внимательно следите за тем, чтобы не возникло путаницы или процессов без входящих, исходящих и других важных элементов. Например, если в приведенном выше примере, я посчитаю нужным сместить точку зрения на копирайтера, я удалю из схемы автора. И тогда управляющие элементы «опыт автора и сторонние источники», а также план публикации становятся ненужными. Ведь ими пользуется автор. Копирайтер работает с аудиофайлом. И если они останутся в общей схеме, то при детализации будут вести непонятно куда и вносить путаницу.
Аналогично, если я решу добавить какой-то блок, важно убедиться, чтобы он также имел все необходимые атрибуты. Здесь очень важна внимательность, так как при моделировании сложных бизнес-процессов изменения в одной части модели могут повлечь за собой изменения в другой. Их обязательно нужно внести.
Правила названия управляющих элементов и блоков
Важно запомнить простое правило: управляющие стрелки называют именами существительными, блоки – глаголами. Так принято в стандарте IDEF0, и такой подход помогает избежать путаницы и ошибок.
Чаще всего ошибки допускают при названии блоков. Например, вместо «Создать статью» пишут «Создание статьи». Блоки в данном подходе – это действия, а потому они должны быть всегда глаголами.
Выгоды использования IDEF0
- Самая первая выгода очевидна – это наглядность. Вы сами начинаете понимать, как работает та или иная система, и можете также наглядно пояснить, где в этой системе «тонкие места» и как ваши решения помогут избавиться от них.
- Взаимопонимание и отсутствие разночтений. При обсуждении работы компании с использованием функциональной модели у вас имеются наглядные и понятные интуитивно блоки задач с управляющими элементами. Кроме того, функциональное моделирование предполагает создание в случае необходимости глоссария, в котором раскрываются условные обозначения и термины. В результате вы с клиентом, руководителем, другими сотрудниками при обсуждении проблемы говорите на одном языке.
- Простота и высокая скорость создания модели. Конечно, научиться моделированию не так просто, как кажется. Ведь схема - это, по сути, сверхплотная подача информации, что очень хорошо для понимания, но для реализации такой подачи требуется особый подход. Мозг аналитика выступает в данном случае как очень мощный пресс с одной стороны, и фильтр – с другой. Но с опытом этот процесс становится очень быстрым. В результате вы получаете инструмент, который поможет и самому разобраться, что же происходит в той или иной системе, и при помощи созданного в сжатые сроки наглядного пособия проиллюстрировать важные моменты коллегам или заказчикам.
- Дисциплина и отсутствие ошибок. Стандарт IDEF0 предполагает строгие рамки и правила. Такой подход дисциплинирует, а привычка действовать в рамках стандарта помогает избежать ошибок по невнимательности. Любые нарушения стандарта становятся сразу заметны.
В чем трудность применения IDEF0
Важно понимать, что только в самых простых случаях два бизнес-аналитика создадут для описания работы компании абсолютно одинаковые функциональные модели. Любая модель – это отражение опыта аналитика, глубины понимания работы бизнеса, который он стремится описать, а также, в некотором роде, его личная точка зрения на этот бизнес. Т.е. человек разрабатывает бизнес-модель с точки зрения руководителя, как будто этим руководителем является именно он.
При этом я считаю, что бизнес-аналитик - это не совсем профессия, бизнес-аналитикой занимается каждый руководитель бизнеса или разработчик каких-то систем, который анализирует бизнес и стремится выстроить наиболее эффективную систему. Именно для этих людей и для этих целей предназначен инструмент IDEF0.
А потому очень важно при составлении функциональной бизнес модели «как есть» постоянно советоваться с руководителем компании, чтобы не совершить ошибки, которая повлечет за собой автоматически ошибки на этапах декомпозиции. Также на последующих этапах могут потребоваться дополнительные согласования с руководителями структурных подразделений и сотрудниками. Только если ваша функциональная модель «как есть» будет действительно отражать реальное положение вещей, можно вносить какие-то изменения и предложения. А для достижения качественных результатов в такой работе требуется, прежде всего, практический опыт и знание особенностей того или иного вида бизнеса.
Министерство образования и науки РФ
Федеральное агентство по образованию
Государственное образовательное учреждение высшего профессионального образования
Курсовая работа
«Моделирование систем»
«Разработка модели предприятия тепличного хозяйства, используя методологии проектирования IDEF0, DFD и IDEF3»
1. Цель работы
2. Теоретическое введение
3. Описание предметной области
4. Описание BPwin
4.1 Принцип построения модели IDEF0
4.2 Принцип построения модели DFD
4.3 Принцип построения модели IDEF3
5. Моделирование
5.1 Модель тепличного хозяйства
5.2 Математическая модель
6. Сравнительный анализ
6.1 Методологии
6.2 Сравнение инструментальных средств
Литература
1. Цель работы
Целями данной курсовой работы были:
применение методов предпроектного обследования предприятия;
анализ полученных материалов для последующего моделирования;
разработка модели процесса в стандарте IDEF0;
описание документооборота и обработки информации в стандарте DFD;
описания процессов в стандарте IDEF3;
разработка смешанной модели описания процесса на основе стандартов IDEFO, DFD и IDEF3.
создание сценариев работы предприятия;
построение структурной схемы предприятия;
создание математической модели данного предприятия.
сравнительный анализ
2. Теоретическое введение
При разработке автоматизированных систем управления на этапах кодирования и тестирования выявляется большое количество ошибок, исправление которых влечет за собой кардинальное изменение всей разрабатываемой системы. Такие ошибки учитываются при моделировании и глубоком, детальном анализе создаваемых проектов. Моделирование позволяет «увидеть» проект в процессе разработки и создать предпосылки для анализа поведения системы в зависимости от начальных условий.
Для правильного координирования процессов протекающих в моделированной системе управления необходимо создать структуру, т.е. упорядочить процессы. Моделирование работы информационной системы особенно важно на первых этапах её создания. Так как исправление допущенных на этом этапе ошибок обходится наиболее дорого, то и польза на этапе анализа задачи и разработки логической модели её решения значительна.
В связи с этим, необходимо изучить и разработать предметную область, а именно работу тепличного хозяйства. Для этого требуется разобраться с терминологией данной области, собрать необходимые нормативные и правовые документы, изучить образцы документов данного предприятия и проследить их перемещение как внутри предприятия, так и за его пределами.
Следующим этапом разработки является этап проектирования. Перед началом проектирования и реализации нужно иметь точное и детальное понимание требований на высоком уровне. Кроме того, очень полезно иметь структуру требований, которая может быть использована как исходные данные для формирования системы. Все это достигается посредством анализа и моделирования.
В процессе работы на этапах моделирования и проектирования необходимо получить проект системы, содержащий достаточно информации для её реализации. Также необходимо произвести анализ работы тепличного хозяйства, в результате которого можно судить о степени загруженности каждого отдела, о том, что необходимо автоматизировать в первую очередь и какими средствами.
Основными целями моделирования при разработке проектов являются:
представление деятельности предприятия и принятых в нем технологий в виде иерархии диаграмм, обеспечивающих наглядность и полноту их отображения;
формирование на основании анализа предложений по реорганизации организационно-управленческой структуры;
упорядочивание информационных потоков (в том числе документооборота) внутри предприятия;
анализ требований и проектирование спецификаций корпоративных информационных систем.
3. Описание предметной области
Для рассмотрения в данной курсовой работе было взято за основу работа тепличного хозяйства. Это предприятие специализируется на выращивании сельскохозяйственных культур. Реализация продукции производится по заявке заказчика.
Организация работы осуществляется по следующей схеме:
В данной схеме указаны отделы предприятия, их функции и взаимосвязь. Некоторые из отделов могут быть автоматизированы.
Во главе всего предприятия стоит руководство, в лице начальника и его заместителя. Их основной функцией является контроль деятельности предприятия.
Служба охраны труда, основная функция которого подготовка персонала;
Бухгалтерский отдел занимается документооборотом;
Служба контроля за производством, осуществляет полноценный контроль на всех стадия производства;
Сектор технического обслуживания, занимается ремонтными работами.
Отделы, службы и рабочие места данного предприятия представлены в таблице №1:
таблица №1
Задачи и функции нашего тепличного хозяйства показаны в таблице №2:
Таблица №2
Документация представлена в таблицах №3:
таблица №3
Справочник организаций представлен в таблице №4:
таблица №4
Далее приведена схема, описывающая сценарий работы предприятия с соответствующими выводами по каждому из этапов: от заказчика поступает заявка на поставку определенной продукции тепличного хозяйства менеджеру по продажам. Он по продажам обрабатывает эту заявку и принимает решение. Параллельно этому бухгалтер производит расчет стоимости оказания услуг. Как только все эти этапы пройдены, начинается процесс заключения контракта. Менеджер по продажам обсуждает с заказчиком условия контракта и производит его заключение. После этого заказчик вносит платеж. Контроль над внесением платежа входит в обязанность бухгалтерии. Бухгалтер получает выписку из банка, и формирует приказ о начале выполнения заказа, который передается технологу. Технолог в свою очередь составляет план – график проводимых работ и ведет учет необходимых средств. После составления плана – графика работ, отдается приказ садовнику об осуществлении земельных работ. Садовник проводит земельные работы и собирает урожай. Собранный урожай отправляется заказчику. По ходу всего производственного цикла к начальнику предприятия поступают отчеты о деятельности менеджера по продажам, бухгалтера и технолога. Начальник контролирует весь процесс деятельности предприятия, и если необходимо, делает замечания по работе его персонала с целью улучшения процесса производства и работы всего предприятия в целом.
Схема сценария работы предприятия
4. Описание BPwin
BPwin относится к малым интегрированным средствам моделирования, которые поддерживают несколько типов моделей и методов.
Для проведения анализа и реорганизации бизнес-процессов Logic Works предлагает CASE-средство верхнего уровня - BPwin, поддерживающее методологии IDEF0 (функциональная модель), IDEF3 (WorkFlow Diagram) и DFD (DataFlow Diagram). Основной из трех методологий, является IDEF0. BPwin имеет достаточно простой и интуитивно понятный интерфейс пользователя, дающий возможность аналитику создавать сложные модели при минимальных усилиях.
BPwin автоматизирует задачи, связанные с построением моделей развития, обеспечивая семантическую строгость, необходимую для гарантирования правильности и непротиворечивости результатов. Это достигается применением в BPwin следующих методологий: IDEF0, DFD и IDEF3.
Но прежде чем заниматься этой, более сложной, задачей, необходимо, действительно, по крайней мере "пересчитать" все элементы бизнеса, то есть создать оргштатную структуру компании. Следующий этап - попытаться графически изобразить взаимосвязи между различными элементами ранее определенной структуры.
В BPwin возможно построение смешанных моделей, т. е. модель может содержать одновременно как диаграммы IDEFO, так и IDEF3 и DFD. Модель в BPwin рассматривается как совокупность работ, каждая из которых оперирует с некоторым набором данных. Работа изображается в виде прямоугольников, данные – в виде стрелок.
Все работы модели нумеруются. Номер состоит из префикса и числа. Может быть использован префикс любой длины, но обычно используют префикс А. Контекстная (корневая) работа дерева имеет номер А0. Работа декомпозиции А0 имеет номера Al, A2, A3 и т.д. Работы декомпозиции нижнего уровня имеют номер родительской работы и очередной порядковый номер, например работы декомпозиции A3 будут иметь номера А3.1 А3.2, АЗ.З, А3.4 и т. д.
В результате дополнения диаграмм, IDEFO диаграммами DFD и IDEF3 может быть создана смешанная модель, которая наилучшим образом описывает все стороны деятельности предприятия. Иерархию работ смешанной модели можно увидеть в окне Model Explorer. Работы в нотации IDEFO изображаются зеленым цветом, DFD – синим.
BPwin так же как и локальные интегрированные системы, практически не позволяют выполнить комплексный анализ систем, который в большей или меньшей степени необходим для создания малых, средних и крупных ИСУП. С их помощью можно разрабатывать локальные ИС или небольшие подсистемы, предназначенные для автоматизации отдельных бизнес-цепочек, т. е. когда нет необходимости в комплексном анализе предприятия. Типичная сфера использования малых интегрированных средств - решение задач так называемой “кусочной” автоматизации предприятия.
4.1 Принцип построения модели IDEFO
Основу методологии IDEFO составляет графический язык описания бизнес-процессов. Модель в нотации IDEFO представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Каждая диаграмма является единицей описания системы и располагается на отдельном листе.
IDEFO-модель предполагает наличие четко сформулированной цели единственного субъекта моделирования и одной точки зрения.
Модель может содержать четыре типа диаграмм:
контекстную диаграмму (в каждой модели может быть только одна контекстная диаграмма);
диаграммы декомпозиции;
диаграммы дерева узлов;
диаграммы только для экспозиции (FEO).
Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и ее взаимодействия с внешней средой.
Этот процесс называется функциональной декомпозицией, а диаграммы, которые описывают каждый фрагмент и взаимодействие фрагментов, называются диаграммами декомпозиции.
В основе нотации и методологии IDEF0 лежит понятие "блока", то есть прямоугольника, который выражает некоторую функцию бизнеса. Как известно, прямоугольник имеет четыре стороны. В IDEF0 роли (функциональные значения) всех сторон различны:
верхняя сторона имеет значение "управления";
левая - "входа";
правая - "выхода";
нижняя - "механизма".
Вторым элементом методологии и нотации является "поток" (в стандарте называемый - "интерфейсная дуга") - элемент, описывающий данные, неформальное управление, или что-либо другое "оказывающее влияние" на функцию, изображенную блоком. В зависимости от того, к какой стороне блока направлен поток, он, соответственно, носит название "входной", "выходной", "управляющий".
Изобразительным элементом, представляющим "поток", является стрелка.
Управление - это что управляет деятельностью бюро, в данной разрабатываемой модели - это законы об индивидуальном ПУ.
Стрелки "входа" вносят функции входных данных, в контекстной диаграмме – это персональные данные работника.
Стрелки "выхода" – выходные данные. В контекстной диаграмме – это различные сведения, которые подаются в Пенсионный фонд РФ.
Стрелка "механизма" - это влияющие на процессы данные. В диаграмме – это персонал и ПК.
После декомпозиции контекстной диаграммы проводится декомпозиция каждого большого фрагмента системы на более мелкие, при этом каждому фрагменту задается имя и так далее, до достижения нужного уровня подробности описания.
После каждого сеанса декомпозиции проводятся сеансы экспертизы - эксперты предметной области указывают на соответствие реальных бизнес-процессов созданным диаграммам.
Найденные несоответствия исправляются, и только после прохождения экспертизы без замечаний можно приступать к следующему сеансу декомпозиции. Так достигается соответствие.
Все перекрестки на диаграмме нумеруются, каждый номер имеет префикс J. Можно редактировать свойства перекрестка при помощи диалога Definition Editor.
4.2 Принцип построения модели DFD
Диаграммы потоков данных (DFD) являются основным средством моделирования функциональных требований проектируемой системы. С их помощью эти требования разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных. Главная цель таких средств - продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.
Для изображения DFD традиционно используются две различные нотации: Йодана (Yourdon) и Гейна-Сарсона (Gane-Sarson). Далее при построении примеров будет использоваться нотация Йодана, все исключения будут предварительно оговариваться.
В основе данной методологии (методологии Gane/Sarson) лежит построение модели анализируемой ИС - проектируемой или реально существующей. В соответствии с методологией модель системы определяется как иерархия диаграмм потоков данных (ДПД или DFD), описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи пользователю. Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы ИС с внешними входами и выходами. Они детализируются при помощи диаграмм нижнего уровня. Такая декомпозиция продолжается, создавая многоуровневую иерархию диаграмм, до тех пор, пока не будет достигнут такой уровень декомпозиции, на котором процесс становятся элементарными и детализировать их далее невозможно.
Источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те в свою очередь преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям - потребителям информации. Таким образом, основными компонентами диаграмм потоков данных являются:
внешние сущности;
системы/подсистемы;
процессы;
накопители данных;
потоки данных.
4.3 Принцип построения модели IDEF3
IDEF3 может быть также использован как метод создания процессов. IDEF3 дополняет IDEFO и содержит все необходимое для построения моделей, которые в дальнейшем могут быть использованы для имитационного анализа.
Каждая работа в IDEF3 описывает какой-либо сценарий бизнес-процесса и может являться составляющей другой работы. Поскольку сценарий описывает цель и рамки модели, важно, чтобы работы именовались отглагольным существительным, обозначающим процесс действия, или фразой, содержащей такое существительное.
Точка зрения на модель должна быть задокументирована. Обычно это точка зрения человека, ответственного за работу в целом. Также необходимо задокументировать цель модели – те вопросы, на которые призвана ответить модель.
Перекрестки (Junction). Окончание одной работы может служить сигналом к началу нескольких работ или же одна работа для своего запуска может ожидать окончания нескольких работ. Перекрестки используются для отображения логики взаимодействия стрелок при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Типы перекрёстков представлены в табл.:
Типы перекрестков
| Обозначение | Наименование | Смысл в случае слияния стрелок (Fan-in Junction) | Смысл в случае разветвления стрелок (Fan-out Junction) |
| ||& | Asynchronous AND | Все предшествующие процессы должны быть завершены | Все следующие процессы должны быть запущены |
| ||&|| | Synchronous AND | Все предшествующие процессы завершены одновременно | Все следующие процессы запускаются одновременно |
| ||O | Asynchronous OR | Один или несколько предшествующих процессов должны быть завершены | Один или несколько следующих процессов должны быть запущены |
| ||O|| | Synchronous OR | Один или несколько предшествующих процессов завершены одновременно | Один или несколько следующих процессов запускаются одновременно |
| ||X | Только один предшествующий процесс завершен | Только один следующий процесс запускается |
Все перекрестки на диаграмме нумеруются, каждый номер имеет префикс J. Можно редактировать свойства перекрестка при помощи диалога Definition Editor. В отличие от IDEFO и DFD в IDEF3 стрелки могут сливаться и разветвляться только через перекрестки.
Объект ссылки. Объект ссылки в IDEF3 выражает некую идею, концепцию или данные, которые нельзя связать со стрелкой, перекрестком или работой. Для внесения объекта ссылки служит кнопка |R| – (добавить в диаграмму объект ссылки - Referent) в палитре инструментов. Объект ссылки изображается в виде прямоугольника, похожего на прямоугольник работы. Имя объекта ссылки задается в диалоге Referent (пункт всплывающего меню Name Editor), в качестве имени можно использовать имя какой-либо стрелки с других диаграмм или имя сущности из модели данных. Объекты ссылки должны быть связаны с единицами работ или перекрестками пунктирными линиями. Официальная спецификация IDEF3 различает три стиля объектов ссылок – безусловные (unconditional), синхронные (synchronous) и асинхронные (asynchronous). BPwin поддерживает только безусловные объекты ссылок. Синхронные и асинхронные объекты ссылок, используемые в диаграммах переходов состояний объектов, не поддерживаются.
5. Моделирование
5.1 Модель тепличного хозяйства
Навигатор модели – Model Explorer
Контекстная диаграмма:
Диаграмма декомпозиции А0:
Диаграмма декомпозиции А1:
Диаграмма IDEF3 A11.1:
Диаграмма потоков данных А12:
Диаграмма декомпозиции А2:
Диаграмма IDEF3 A21.1:
Диаграмма декомпозиции А3:
Диаграмма декомпозиции А4:
Диаграмма декомпозиции А5:
Диаграмма декомпозиции А6:
Диаграмма потоков данных А63:
5.2 Математическая модель
Для более подробного описания работы тепличного хозяйства необходимо составить математическую модель для продукта деятельности предприятия.
Данная математическая модель будет описывать расчет цены за единицу товара в разных условиях.
e - себестоимость единицы товара, определяется производителем, в нее входят все издержки связанные с производством единицы товара, основную часть этой цифры составляет цена закупки семян;
v - цена закупки семян, это цена по которой предприятие закупило семена у поставщика (раздел «закупка семян»);
а - расход на труд (заработная плата и прочие расходы внутри предприятия);
g – ГСМ (горюче-смазочные материалы);
n – налоги (потребительская часть) устанавливаются государством и имеют фиксированную ставку;
k – НДС, налог на добавочную стоимость, так же имеет фиксированную ставку;
r – розничная цена, это сумма денег за которую производитель продает единицу своего товара на рынка, как правило розничная цена определяется себестоимостью с определенным процентом наценки;
s – наценка предприятия на единицу товара, как правило её количество определяет каждый предприниматель индивидуально, в данном случае она составляет 40% от себестоимости, т. е. (e*40)/100
о – оптовая цена, это сума денег предлагаемой за единицу товара, при покупке от 100 единиц, в этом случае действует скидка 10% от розничной цены;
os – скидка при оптовой покупке (os Математическая модель расчета себестоимости за единицу произведенного товара: Математическая модель расчета розничной цены за единицу произведенного товара: Математическая модель расчета оптовой цены за единицу произведенного товара: o= v+a+g+n+k+s - os o=r - (r*10)/100 Расчетом стоимости продукции на предприятии «Тепличное хозяйство» занимается бухгалтерский отдел, который производит контроль над документооборотом, учитывает доходы и расходы предприятия, ведет учетные книги, выдает справки. На основании данных формул, полученных в математической модели предприятия, бухгалтер может рассчитать цену товара, как розничного, так и оптового. 6. Сравнительный анализ
Для моделирования нашего предприятия нами было использовано 5 методологий: Дракон, UML, IDEF0, IDEF3, DFD. На наш взгляд наилучшим вариантом представления модели нашего предприятия является методология UML, так как она более наглядно и точно отображает основные аспекты работы тепличного хозяйства. Диаграммы UML сравнительно просты для чтения. Например, диаграмма «Вариантов использования», которая была использована в результате проектирования системы реализации Тепличного хозяйства, дает, возможность заказчику, конечному пользователю и разработчику совместно обсуждать функциональность и поведение системы. «Диаграмма классов» позволяет описывать структуру системы, она демонстрирует классы системы, их атрибуты, методы и зависимости между классами, что подробно может раскрыть сценарий и организацию работы предприятия. Методология Дракон так же имеет очень понятную структуру, но не имеет таких широких возможностей по моделированию различных систем. Visio - наиболее простое и доступное средство моделирования процессов. Этот продукт имеет стандартные, привычные всем панели управлении в стиле MS Office и легко интегрируется с любыми приложениями этого пакета, что упрощает работу с ним для неопытных пользователей. Однако для временного или стоимостного анализа требуется разработка отчетов, что значительно усложняет использование этого продукта. Типовые отчеты явно не достаточны для анализа бизнес-процессов. Несмотря на это, Visio является распространенным средством для описания бизнес-процессов как в России, так и за рубежом. Visio поддерживает IDEF и UML форматы для описания бизнес-процессов. Возможна также самостоятельная разработка форматов. BPWIN - занимает промежуточное место, отличаясь достаточной простотой и большими возможностями анализа. Функциональность BPWIN заключается не только в рисовании диаграмм, но и в проверке целостности и согласованности модели. BPWIN обеспечивает логическую четкость в определении и описании элементов диаграмм, а также проверку целостности связей между диаграммами. Инструмент обеспечивает коррекцию наиболее часто встречающихся ошибок при моделировании. Кроме того, BPWIN поддерживает пользовательские свойства, которые применяются к элементам диаграммы для описания специфических свойств, присущих данному элементу. Основным ограничением этой системы является положенный в ее основу стандарт IDEF, в котором существуют жесткие ограничения при построении моделей. Это упрощает задачу при описании простых процедур, но усложняет описание больших процессов. Схемы 1DEF при описании сложных процессов начинают представлять бесчисленное множество взаимосвязанных схем, внешне очень похожих, что затрудняет понимание процесса в целом. 7. Вывод:
В ходе выполнения данной курсовой работы были достигнуты все поставленные нами цели. В связи с этим, нами была изучена разрабатываемая предметная область, а именно работа тепличного хозяйства. Для этого потребовалось разобраться с терминологией данной области, собрать необходимые нормативные и правовые документы, изучить образцы документов нашего предприятия и проследить их перемещение как внутри предприятия, так и за его пределами. В результате проведения этих мероприятии была получена информация, на основе которой проведен первоначальный анализ и составлены наброски проектируемой модели. Следующим этапом разработки является этап проектирования. Перед началом проектирования и реализации нужно иметь точное и детальное понимание требований на высоком уровне. Кроме того, очень полезно иметь структуру требований, которая может быть использована как исходные данные для формирования системы. Все это достигается посредством анализа и моделирования. Выполняя анализ и моделирования, мы добились разделения задач, которые в предпроектном состоянии мы готовили и упрощали для последующей деятельности по проектированию и реализации. Разграничиваем проблемы, которые должны быть решены, и решения, которые должны быть приняты для того, чтобы справиться с ними. В результате работы на этапах моделирования и проектирования мы получили проект системы, содержащий достаточно информации для её реализации. После анализа работы тепличного хозяйства мы можем судить о степени загруженности каждого отдела, о том, что необходимо автоматизировать в первую очередь и какими средствами. Для облегчения работы можно внедрить новые технологии, которые облегчат работу в нашем хозяйстве. Литература:
Рогозов Ю.И., Стукотий Л.Н., Свиридов А.С. «Моделирование систем» ТРТУ, 2004. С.В. Маклаков «CASE-средства разработки информационных систем. BPwin и Erwin» –М.: ДиалогМифи, 2001. Маклаков С. «Объединение структурного и объектного подхода в новом поколении CASE-средств Computer Associates» // Учебно-консалтинговый центр. 2002.
IDEF0: что такое и как используется
Зачастую к разработчикам обращаются с просьбой не просто выявить и решить какую-либо проблему в работе компании, но и определить, какую роль она играет в структуре компании. Потому как куда важнее понять, каким образом неправильно функционирующее подразделение взаимодействует с другими, чем просто понять, почему она работает неправильно. Поэтому выявление любой проблемы начинается с изучения работы компании и составления её функциональной модели.
Вы скажете, что функциональная модель компании должна быть у руководителя вне зависимости от того, о какой компании идет речь. Но, как показывает практика, в большинстве случаев эта модель отсутствует.
Преимущество графики
Что представляет собой модели IDEF0? Графические схемы со своими особенностями и правила их построения. Почему именно графика? Потому что она эффективна. В этом можно убедиться на нескольких примерах.
Давайте представим себе, что военные план боевых действий объясняли словами, а не с помощью карт, с нанесенными на них графическими обозначениями. Сейчас это кажется невозможным, а ведь до второй половины 19 века именно так и было. Графика помогает понять то, что объяснить и, соответственно, разобраться в чем достаточно трудно.
Так же и с бизнес-процессами: многие технические задания можно оформить в виде графических нотаций, что существенно упростит выполнения задания разработчикам, а клиентам сэкономит денежные средства.
Преимущества IDEF0 для IT -специалистов
Деятельность разработчиков, будь то, к примеру, установка CRM или создание эффективной ERP, связана с внесением изменений в уже сложившуюся систему. А чтобы сделать это правильно, нужно в первую очередь изучить, как устроена эта система. После ее изучения разработчик пишет коммерческое предложение, в котором излагает свое видение ситуации, действия, необходимые для решения поставленной задачи, а также предполагаемый результат. Такой документ может занимать не один десяток страниц. Это, с одной стороны, хорошо, ведь клиент получает максимум интересующей его информации. С другой стороны, на изучение объемного текста нужно время, которого у успешного бизнесмена зачастую нет.
Так как же доступно донести суть, не прибегая к объемным текстам? Графика! Именно она позволяет сократить написанное, наглядно демонстрируя нужную информацию. Ведь одно изображение способно заменить сотни слов. И применительно к использованию графики при описании бизнес-процессов – это на 100% верно.
Давайте для начала разберемся, что такое нотация и IDEF0 и для чего они нужны.
Нотация описания бизнес-процессов: что это такое
Нотация – формат, в котором бизнес-процессы представлены в виде графических объектов, использующихся при моделировании, и непосредственно правила моделирования. Нотация – своеобразный графический язык, позволяющий представить функционирование компании, демонстрирующий связь между отделами и подразделениями. То есть, нотацию можно считать своеобразным языком программирования в бизнес-аналитике.
IDEF0 – это…
IDEF0 – метод функционального моделирования, а также графическая нотация, которая используется для описания и формализации бизнес-процессов. Особенность IDEF0 заключается в том, что эта методология ориентирована на соподчиненность объектов. IDEF0 была разработана для автоматизации предприятий еще в 1981 году в США.
Функциональная модель компании
Функциональная модель IDEF0 – это блоки, каждый из которых имеет несколько входов и выходов. В каждом блоке есть управление и механизмы, детализирующиеся до необходимого уровня. В левом верхнем углу расположена самая важная функция. Она соединяется с остальными стрелками и описаниями функциональных блоков. У каждой стрелки или активности есть свое значение. Благодаря этому такая модель используется для описания любых административных и организационных процессов.
Типы стрелок
Входящими ставятся задачи.
Исходящими выводят результат деятельности.
Управляющие (стрелки сверху вниз) – это механизмы управления.
Механизмы (стрелки снизу вверх) используются для проведения необходимых работ.
При работе с функциональной моделью приняты следующие правила. К примеру, стрелки получают названия именами существительными (правила, план и т.д.), блоки – глаголами (провести учет, заключить договор).
IDEF0 позволяет обмениваться информацией, при этом благодаря универсальности и наглядности участники обмена легко поймут друг друга. IDEF0 тщательно разрабатывался и совершенствовался, работать с IDEF0 можно с помощью различных инструментов, к примеру, ERWIN, VISIO, Bussines studio.
У IDEF0 есть еще оно неоспоримое преимущество. Эта методика была разработана сравнительно давно, и за три десятилетия она прошла тщательную шлифовку и корректировку. Поэтому создать функциональную модель компании можно быстро и минимальной вероятностью ошибки.
Естественно, есть и другие методологии, так почему мы рекомендуем именно IDEF0? Отпилить кусок металлической трубы можно и ножовкой, но, согласитесь, сделать это гораздо проще с помощью болгарки. Так и с IDEF0: нет более функционального инструмента для моделирования, с ним получить вы легко и быстро получите нужный вам результат.
Как создается функциональная модель
Разберем создание функциональной модели на примере написания статьи.
Основной блок будет так и называться «Написание статьи».
То, что необходимо для написания статьи, отражается на входящих стрелках – «Опыт», «Дополнительная литература».
Управляющие стрелки для написания статьи – «План статьи», «Требования к оформлению», «Правила русского языка».
Механизмы – это непосредственно сам автор, копирайтер, редактор, программное обеспечение. Как организуется работа этих механизмов? Автор создает текст, записывая его аудиоверсию. Копирайтер переносит текст в текстовый формат, ориентируясь на план публикации, соблюдая требования издателя и правила русского языка. Затем к работе подключается редактор, который проверяет статью, исправляя речевые, орфографические и пунктуационные ошибки. Программное обеспечение – это те программы и инструменты, которыми пользовались участники процесса при создании статьи.
Все вышеописанное – только общая схема работы, поэтому ее нужно детализировать.
Вернемся к нашей модели и декомпозируем общий блок на несколько связанных между собой элементов.
Так, весь процесс написания статьи можно разделить на 4 этапа:
- Подготовить аудиоверсию.
- Подготовить текст в печатном виде.
- Редактирование и подготовка текста к печати.
- Публикация статьи.
На схеме отражается информация о том,какие управляющие элементы и механизмы участвуют на каком этапе. К примеру, для того чтобы создать качественный текст, автор пользуется собственным опытом и знаниями, в качестве руководства использует план публикации и требования, предъявляемые издателем. Копирайтер, создавая печатный вариант текста, и редактор при его корректировке пользуются правилами русского языка. Для публикации статьи, например, в интернет-издании, требуется специальное программное обеспечение.
При подготовке функциональной модели исполнитель ориентируется на цель ее создания и свою точку зрения.
Функциональное моделирование эффективно используется при принятии различных управленческих решений. В приведенном нами примере процесса написания статьи два специалиста – копирайтер и редактор. И при необходимой оптимизации финансирования проекта по схеме несложно определить, как это сделать. У копирайтера и корректора схожие методы работы, поэтому всю работу можно предложить выполнить копирайтеру, так как он работает непосредственно с аудиотекстом, чего редактор делать не умеет. При этом копирайтеру можно предложить выполнить эту работу за половину той суммы, которая предназначалась редактору. Да, от этого, возможно, потеряется качество текста, но задача оптимизации была выполнена успешно. А сделать это без наглядной схемы было бы сложнее.
Процесс создания нотации IDEF0
Для создания нотаций существует много программ. Одни предназначены для создания функциональных моделей, другие же позволяют работать с любыми графическими объектами. А кому-то на первом этап достаточно листа бумаги, карандаша и ластика.
Прежде чем приступать к описанию работы компании, то есть непосредственно к созданию нотации бизнес-процессов, следует изучить принципы функционирования компании. Для этого сторонним специалистом проводится интервью. В первую очередь на вопрос отвечает руководитель компании, потом специалисты, которые курируют другие этапы работы.
Результатом первого этапа работы становятся две нотации. В одной будут отражаться бизнес-процессы в их первозданном виде. Эта нотация будет создана по результатам интервью, причем каждая деталь должна согласовываться с руководителем компании и ее сотрудниками. Крайне важно, чтобы ваше представление о существующих в компании бизнес-процессах совпадало с действительностью, для этого требуется подтверждение на всех уровнях.
Вторую нотацию можно назвать «Как должно быть». Она создается на основе первой с изменениями, внесенными в соответствии с поставленной задачей.
Стандарт IDEF0 и его требования
О базовых требованиях IDEF0 мы говорили чуть выше.
- Главный элемент – в верхнем левом углу.
- Каждый элемент должен иметь входящие и исходящие стрелки. Причем входящие стрелки находятся слева, справа – исходящие.
- Сверху располагаются управляющие элементы, снизу – механизмы.
- При расположении нескольких блоков на одном листе или экране последующие размещаются справа внизу от предыдущего.
- Схемы следует создавать так, чтобы стрелки пересекались минимальное количество раз.
Ошибки при работе с IDEF0
Как и в любой другой деятельности, при выполнении функционального моделирования случаются ошибки. Разберем наиболее типичные из них.
Использование нескольких цветов
Важно запомнить, что в функциональном моделировании важны все элементы, нет более важных или менее важных. При моделировании на бумаге или в одной из компьютерных программ пользователи пытаются сделать схему более наглядной, раскрашивая блоки и стрелки разным цветом. Однако на практике это не только не делает схему более наглядной, а наоборот, приводит к путанице и к тому, что искажается восприятие изображенного.
Поэтому идеальный вариант – черно-белая схема без использования дополнительных цветовых вариантов. Это не только поможет исключить недоразумения, но и дисциплинирует непосредственно создателя модели, что благоприятно сказывается на читабельности и наглядности модели.
Большое количество блоков
Составляя функциональную модель работы компании, зачастую ее авторы стараются отразить все, даже мельчайшие подробности. Получается схема с огромным количеством блоков и стрелок. В результате снижается ее читабельность и наглядность.
Чтобы избежать этой ошибки, воспользуйтесь детализацией, которой будет остаточно для понимания вопроса. Подробная детализация готовится лишь в том случае, если она действительно нужна для решения важного вопроса.
Изменение структуры при исправлении ошибок
При создании схемы важно, чтобы не один процесс не остался без входящих, исходящих или иных важных элементов. К примеру, если нужно удалить из схемы автора, то нужно удалять все элементы и стрелки, непосредственно к нему относящиеся. Если же они останутся в схеме, то возникнет недоразумение и путаница, так как при детализации будут вести неизвестно куда.
Та же ситуация возникает с добавлением блока. Если нужно внести какую-либо информацию, проверьте, снабдили ли вы ее необходимыми атрибутами. За этим нужно внимательно следить, так как при моделировании сложных бизнес-процессов даже незначительное изменение в одной части повлечет за собой изменения в другой.
Название блоков и управляющих элементов
Правила названия элементов модели достаточно простое, но крайне важно его запомнить: управляющие стрелки называются именами существительными, блоки – глаголами. Это правило прописано в стандарте IDEF0, оно помогает избежать путаницы и возникновения ошибок.
Преимущества использования IDEF0
Наглядность. Изобразив работу компании в виде схемы, становится понятным, как работает компания, где могут возникнуть проблемы и как предупредить их появление.
Взаимопонимание, исключение возможности неправильной трактовки схемы. Наглядность и доступность функциональной модели, представляющей работу компании в виде блоков и управляющих элементов, помогут вам при обсуждении с руководством функционирования их компании. Кстати, в случае необходимости к функциональной модели создается глоссарий, где собраны все термины и условные обозначения. Таким образом, минимизируется возможность возникновения недопонимания между вами и руководителем, сотрудниками компании.
Простота и экономия времени при создании модели. Конечно, для того чтобы хорошо владеть методикой функционального моделирования, нужно потратить много времени. В первую очередь, нужно научиться представлять огромное количество информации в виде лаконичной схемы, т.е. уметь фильтровать и сжимать исходные данные. Но потраченные на обучение силы и время с лихвой окупаются впоследствии. Ведь на то, чтобы создать функциональную модель и доступно представить ее, уже не понадобится много времени.
Минимальная вероятность ошибки. Работа по стандарту IDEF0 требует строгого следования его правилам. Это дисциплинирует исполнителя и исключает возможность возникновения ошибки. К тому же любое несоответствие стандарту сразу же становится заметным.
И напоследок
У двух бизнес-аналитиков функциональные модели могут быть одинаковыми только в том случае, если структура компании крайне проста. В остальных случаях модели будут отличаться одна от другой. Это естественно, ведь у каждого аналитика свой определенный опыт, свое понимание функционирования компании, своя точка зрения на то, как решать поставленные перед ним задачи. Бизнес-аналитик разрабатывает функциональную модель с точки зрения руководителя, представляет, как бы он решил поставленные задачи.
На наш взгляд, инструмент IDEF0 будет полезен не только профессиональным бизнес-аналитикам, но и тем, кто непосредственно анализирует свой бизнес и стремится построить эффективную систему управления.
Антивирус Bitdefender: эффективный защитник Без вопросов
Значение слова неудачный
Обзор Samsung Galaxy A7 (2017): не боится воды и экономии Стоит ли покупать samsung a7
Делаем бэкап прошивки на андроиде
Как настроить файл подкачки?