Моделирование бизнес-процессов на примере трикотажной фабрики
Применение универсальных графических языков IDEF0, IDEF3 и DFD для моделирования бизнес-процессов трикотажной фабрики. Описание предметной области. Характеристика технологии производства трикотажных изделий. Внешние и внутренние сущности и накопители.
Рубрика | Экономико-математическое моделирование |
Вид | курсовая работа |
Язык | русский |
Дата добавления | 01.12.2014 |
Размер файла | 226,6 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
КУРСОВАЯ РАБОТА
по дисциплине
Теоретические основы информатики и имитационное моделирование
Тема:
Моделирование бизнес-процессов на примере трикотажной фабрики
Содержание
Введение
1. Описание методологий семейства IDEF (ICAM Defenition)
1.1 Методология IDEF0
1.2 Методология DFD (Data Flow Diagramming)
1.3 Методология IDEF3
2. Описание предметной области
2.1 Краткая характеристика производства трикотажных изделий
2.2 Описание основных бизнес-процессов трикотажной фабрики
2.3 Описание вспомогательных бизнес-процессов трикотажной фабрики
2.4 Описание внешних сущностей
2.5 Описание внутренних сущностей и накопителей
2.6 Технологический процесс «Производство трикотажных изделий»
Заключение
Список литературы
Введение
В настоящее время в России резко возрос интерес к общепринятым на Западе стандартам менеджмента.
В конце 90-х годов, когда на рынке в должной мере появилась конкуренция и рентабельность деятельности предприятий стала резко падать, руководители ощутили огромные сложности при попытках оптимизировать затраты, чтобы продукция оставалась одновременно и прибыльной и конкурентоспособной. Как раз в этот момент совершенно четко проявилась необходимость иметь перед своими глазами модель деятельности предприятия, которая отражала бы все механизмы и принципы взаимосвязи различных подсистем в рамках одного бизнеса.
Понятие «моделирование бизнес-процессов» пришло в быт большинства аналитиков одновременно с появлением на рынке сложных программных продуктов, предназначенных для комплексной автоматизации управления предприятием. Подобные системы всегда подразумевают проведение глубокого предпроектного обследования деятельности компании. Результатом этого обследование является экспертное заключение, в котором отдельными пунктами выносятся рекомендации по устранению «узких мест» в управлении деятельностью. На основании этого заключения, непосредственно перед проектом внедрения системы автоматизации, проводится так называемая реорганизация бизнес-процессов, иногда достаточно серьезная и болезненная для компании. Это и естественно, сложившийся годами коллектив всегда сложно заставить «думать по-новому». Подобные комплексные обследования предприятий всегда являются сложными и существенно отличающимися от случая к случаю задачами.
Для решения подобных задач моделирования сложных систем существуют хорошо обкатанные методологии и стандарты. К таким стандартам относятся методологии семейства IDEF. С их помощью можно эффективно отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах. При этом широта и глубина обследования процессов в системе определяется самим разработчиком, что позволяет не перегружать создаваемую модель излишними данными.
В настоящее время широко используются CASE_технологии (Computer Aided Software/System Engineering), предоставляющие ряд нотаций для разработки описательных моделей. Одними из самых популярных программных продуктов, обеспечивающих полный цикл анализа, проектирования и кодогенерации, являются автоматизированные инструменты серии Platinum technology (Logic Works): BPWin, ERWin, ModelMart, Paradigm Plus, RPTWin.
BPwin является мощным инструментом для создания моделей, позволяющих анализировать, документировать и планировать изменения сложных бизнес-процессов. BPwin предлагает средство для сбора всей необходимой информации о работе предприятия и графического изображения этой информации в виде целостной и непротиворечивой модели. Причем, поскольку модель является некоторым графическим представлением действительности, можно утверждать, что человек вернулся к своему излюбленному средству документирования бизнес-процессов - к рисунку. Но возвращение это произошло на новом уровне - целостность и непротиворечивость модели-рисунка (качества, о которых раньше не было и речи) гарантируются рядом методологий и нотаций, которым следуют создатели модели. BPwin поддерживает три таких методологии: IDEF0, DFD и IDEF3.
BPwin умеет проверять создаваемые модели с точки зрения синтаксиса выбранной методологии, проверяет ссылочную целостность между диаграммами, а также выполняет ряд других проверок, чтобы помочь вам создать правильную модель, а не просто рисунок. При этом сохраняются главные преимущества рисунка - простота создания и наглядность.
Модель, выполненная в BPwin представляет собой набор иерархически упорядоченных диаграмм (не обязательно сделанных в одной методологии, чаще модели бывают смешанными). При размещении на очередной диаграмме некоторого элемента (работы, стрелки…) этот элемент вместе со всеми своими свойствами (которые всегда можно просмотреть или изменить в соответствующем редакторе BPwin) автоматически заносится в словарь BPwin, в результате вместе с графическим изображением моделируемой системы аналитик получает десятки страниц с подробным текстовым описанием системы.
Применение универсальных графических языков бизнес-моделирования IDEF0, IDEF3 и DFD обеспечивает логическую целостность и полноту описания, необходимую для достижения точных и непротиворечивых результатов. Посредством набора графических инструментов для отображения действий и объектов, BPwin позволяет легко построить схему процесса, на которой показаны исходные данные, результаты операций, ресурсы, необходимые для их выполнения, управляющие воздействия, взаимные связи между отдельными работами. Интерактивное выделение объектов обеспечивает постоянную визуальную обратную связь при построении модели. BРwin поддерживает ссылочную целостность, не допуская определения некорректных связей и гарантируя непротиворечивость отношений между объектами при моделировании.
BPwin тесно интегрируется с рядом известных продуктов Computer Associates и других компаний. Среди этих продуктов:
· Широко известный инструмент моделирования данных ERwin (CA/Logic Works). Erwin не нуждается в рекомендациях. В версии BPwin 4.0 интерфейсы экспорта и импорта синхронизованы с Erwin 4.0. Кроме того, появилась возможность ассоциирования сущностей и атрибутов с хранилищами данных.
· Система управления и хранения проектов ModelMart (CA/Logic Works), которая предоставляет репозитарий для коллективной разработки моделей. ModelMart гарантирует согласованность моделей, разграничение доступа к ним, поддержку версий и много других средств, которые так важны при командной разработке моделей. Сервер приложений для программных продуктов CA ModelMart поддерживает мощный набор инструментальных программных средств, обеспечивающих совместное (групповое) проектирование и разработку программных систем, включая механизмы объединения моделей и анализа изменений, контроль версий, возможность создания «компонент» модели и т.д. Для организации хранилища моделей в ModelMart используются СУБД на платформах Oracle, Sybase, Informix или SQL Server. Кроме того, поддерживаются прямые связи ModelMart с ERwin и BPwin.
· Инструмент стоимостного анализа EasyABC (ABC Technologies).
· В BPwin 4.0 стал возможен экспорт модели в систему имитационного моделирования Arena (Systems Modeling Corp.).
Все вышесказанное позволяет утверждать, что уже сейчас BPwin крайне необходим всем, кто занимается проектированием и анализом бизнес-процессов.
1. Описание методологий семейства IDEF (ICAM Defenition)
1.1 Методология IDEF0
Графический язык IDEF0 удивительно прост и гармоничен. В основе методологии лежат четыре основных понятия:
Первым из них является понятие функционального блока (Activity Box). Функциональный блок графически изображается в виде прямоугольника (см. рис. 1) и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, «производить услуги», а не «производство услуг»). Каждая из четырех сторон функционального блока имеет своё определенное значение (роль), при этом:
· Верхняя сторона имеет значение «Управление» (Control);
· Левая сторона имеет значение «Вход» (Input);
· Правая сторона имеет значение «Выход» (Output);
· Нижняя сторона имеет значение «Механизм» (Mechanism).
Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер.
Рис. 1. Функциональный блок
Вторым «китом» методологии IDEF0 является понятие интерфейсной дуги (Arrow). Также интерфейсные дуги часто называют потоками или стрелками. Интерфейсная дуга отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком.
Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). По требованию стандарта, наименование должно быть оборотом существительного.
С помощью интерфейсных дуг отображают различные объекты, в той или иной степени определяющие процессы, происходящие в системе. Такими объектами могут быть элементы реального мира (детали, вагоны, сотрудники и т.д.) или потоки данных и информации (документы, данные, инструкции и т.д.).
В зависимости от того, к какой из сторон подходит данная интерфейсная дуга, она носит название «входящей», «исходящей» или «управляющей». Кроме того, «источником» (началом) и «приемником» (концом) каждой функциональной дуги могут быть только функциональные блоки, при этом «источником» может быть только выходная сторона блока, а «приемником» любая из трех оставшихся.
Необходимо отметить, что любой функциональный блок по требованиям стандарта должен иметь, по крайней мере, одну управляющую интерфейсную дугу и одну исходящую. Это и понятно - каждый процесс должен происходить по каким-то правилам (отображаемым управляющей дугой) и должен выдавать некоторый результат (выходящая дуга), иначе его рассмотрение не имеет никакого смысла.
Внешне природа входящих и управляющих интерфейсных дуг схожа, однако для систем одного класса всегда есть определенные разграничения. Например, в случае рассмотрения предприятий и организаций существуют пять основных видов объектов: материальные потоки (детали, товары, сырье и т.д.), финансовые потоки (наличные и безналичные, инвестиции и т.д.), потоки документов (коммерческие, финансовые и организационные документы), потоки информации (информация, данные о намерениях, устные распоряжения и т.д.) и ресурсы (сотрудники, станки, машины и т.д.). При этом в различных случаях входящими и исходящими интерфейсными дугами могут отображаться все виды объектов, управляющими только относящиеся к потокам документов и информации, а дугами-механизмами только ресурсы.
Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram).
Третьим основным понятием стандарта IDEF0 является декомпозиция (Decomposition). Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.
Декомпозиция позволяет постепенно и структурировано представлять модель системы в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко усваиваемой.
Модель IDEF0 всегда начинается с представления системы как единого целого - одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором «А_0».
В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint).
Определение и формализация цели разработки IDEF0 - модели является крайне важным моментом. Фактически цель определяет соответствующие области в исследуемой системе, на которых необходимо фокусироваться в первую очередь. Например, если моделируется деятельность предприятия с целью построения в дальнейшем на базе этой модели информационной системы, то эта модель будет существенно отличаться от той, которая бы разрабатывалась для того же самого предприятия, но уже с целью оптимизации логистических цепочек.
Точка зрения определяет основное направление развития модели и уровень необходимой детализации. Четкое фиксирование точки зрения позволяет разгрузить модель, отказавшись от детализации и исследования отдельных элементов, не являющихся необходимыми, исходя из выбранной точки зрения на систему. Например, функциональные модели одного и того же предприятия с точек зрения главного технолога и финансового директора будут существенно различаться по направленности их детализации. Это связано с тем, что в конечном итоге, финансового директора не интересуют аспекты обработки сырья на производственных станках, а главному технологу ни к чему прорисованные схемы финансовых потоков. Правильный выбор точки зрения существенно сокращает временные затраты на построение конечной модели.
В процессе декомпозиции, функциональный блок, который в контекстной диаграмме отображает систему как единое целое, подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы и называется дочерней (Child diagram) по отношению к нему (каждый из функциональных блоков, принадлежащих дочерней диаграмме соответственно называется дочерним блоком - Child Box). В свою очередь, функциональный блок - предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит - родительской диаграммой (Parent Diagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. Важно отметить, что в каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок, или исходящие из него фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0 - модели. Наглядно принцип декомпозиции представлен на рисунке 2. Следует обратить внимание на взаимосвязь нумерации функциональных блоков и диаграмм - каждый блок имеет свой уникальный порядковый номер на диаграмме (цифра в правом нижнем углу прямоугольника), а обозначение под правым углом указывает на номер дочерней для этого блока диаграммы. Отсутствие этого обозначения говорит о том, что декомпозиции для данного блока не существует.
Часто бывают случаи, когда отдельные интерфейсные дуги не имеет смысла продолжать рассматривать в дочерних диаграммах ниже какого-то определенного уровня в иерархии, или наоборот - отдельные дуги не имеют практического смысла выше какого-то уровня. С другой стороны, случается необходимость избавиться от отдельных «концептуальных» интерфейсных дуг и не детализировать их глубже некоторого уровня. Для решения подобных задач в стандарте IDEF0 предусмотрено понятие туннелирования. Обозначение «туннеля» (Arrow Tunnel) в виде двух круглых скобок вокруг начала интерфейсной дуги обозначает, что эта дуга не была унаследована от функционального родительского блока и появилась (из «туннеля») только на этой диаграмме. В свою очередь, такое же обозначение вокруг конца (стрелки) интерфейсной дуги в непосредственной близи от блока - приёмника означает тот факт, что в дочерней по отношению к этому блоку диаграмме эта дуга отображаться и рассматриваться не будет. Чаще всего бывает, что отдельные объекты и соответствующие им интерфейсные дуги не рассматриваются на некоторых промежуточных уровнях иерархии - в таком случае, они сначала «погружаются в туннель», а затем, при необходимости «возвращаются из туннеля».
Последним из понятий IDEF0 является глоссарий (Glossary). Для каждого из элементов IDEF0: диаграмм, функциональных блоков, интерфейсных дуг существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента. Например, для управляющей интерфейсной дуги «распоряжение об оплате» глоссарий может содержать перечень полей соответствующего дуге документа, необходимый набор виз и т.д. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией.
Рис. 2. Декомпозиция функциональных блоков
Обычно IDEF0_модели несут в себе сложную и концентрированную информацию, и для того, чтобы ограничить их перегруженность и сделать удобочитаемыми, в соответствующем стандарте приняты соответствующие ограничения сложности:
· ограничение количества функциональных блоков на диаграмме тремя-шестью. Верхний предел (шесть) заставляет разработчика использовать иерархии при описании сложных предметов, а нижний предел (три) гарантирует, что на соответствующей диаграмме достаточно деталей, чтобы оправдать ее создание;
· ограничение количества подходящих к одному функциональному блоку (выходящих из одного функционального блока) интерфейсных дуг четырьмя.
Разумеется, строго следовать этим ограничениям вовсе необязательно, однако, как показывает опыт, они являются весьма практичными в реальной работе.
Модели 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. В диалоге настройки следует выбрать необходимые поля, при этом автоматически отображается очередность вывода информации в отчет.
1.2 Методология DFD (Data Flow Diagramming)
Диаграммы потоков данных (Data flow diagramming, DFD) используются для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет модельную систему как сеть связанных между собой работ. Их можно использовать как дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота в корпоративных системах обработки информации. DFD описывает:
· функции обработки информации (работы);
· документы (стрелки, arrow), объекты, сотрудников или отделы, которые участвуют в обработке информации;
· внешние ссылки (external references), которые обеспечивают интерфейс с внешними объектами, находящимися за границами моделируемой системы;
· таблицы для хранения документов (хранилище данных, data store).
В BPwin для построения диаграмм потоков данных используется нотация Гейна - Сарсона (рис. 3).
Для того чтобы дополнить модель IDEF0 диаграммой DFD, нужно в процессе декомпозиции в диалоге Activity Box Count «кликнуть» по радио-кнопке DFD. В палитре инструментов на новой диаграмме DFD появляются новые кнопки:
· добавить в диаграмму внешнюю ссылку (External Reference). Внешняя ссылка является источником или приемником данных извне модели;
· добавить в диаграмму хранилище данных (Data store). Хранилище данных позволяет описать данные, которые необходимо сохранить в памяти прежде, чем использовать в работах;
ссылка на другую страницу. В отличие от IDEF0 инструмент offpage reference позволяет
Рис. 3. Основные символы диаграммы потоков данных
· направить стрелку на любую диаграмму (а не только на верхний уровень).
В отличие от стрелок IDEF0, которые представляют собой жесткие взаимосвязи, стрелки DFD показывают, как объекты (включая данные) двигаются от одной работы к другой. Это представление потоков совместно с хранилищами данных и внешними сущностями делает модели DFD более похожими на физические характеристики системы - движение объектов (data flow), хранение объектов (data stores), поставка и распространение объектов (external entities).
В отличие от IDEF0, где система рассматривается как взаимосвязанные работы, DFD рассматривает систему как совокупность предметов. Контекстная диаграмма часто включает работы и внешние ссылки. Работы обычно именуются по названию системы, например «Система обработки информации». Включение внешних ссылок в контекстную диаграмму не отменяет требования методологии четко определить цель, область и единую точку зрения на моделируемую систему.
Работы
В DFD работы представляют собой функции системы, преобразующие входы в выходы. Хотя работы изображаются прямоугольниками со скругленными углами, смысл их совпадает со смыслом работ IDEF0 и IDEF3. Так же как работы IDEF3, они имеют входы и выходы, но не поддерживают управления и механизмы, как IDEF0.
Внешние сущности
Изображают входы в систему и/или выходы из нее. Внешние сущности изображаются в виде прямоугольника с тенью и обычно располагаются по краям диаграммы. Одна внешняя сущность может быть использована многократно на одной или нескольких диаграммах. Обычно такой прием используют, чтобы не рисовать слишком длинных и запутанных стрелок.
Стрелки (Потоки данных)
Стрелки описывают движение объектов из одной части системы в другую. Поскольку в DFD каждая сторона работы не имеет четкого назначения, как в IDEF0, стрелки могут подходить и выходить из любой грани прямоугольника работы. В DFD также применяются двунаправленные стрелки для описания диалогов типа «команда-ответ» между работами, между работой и внешней сущностью и между внешними сущностями.
Хранилище данных
В отличие от стрелок, описывающих объекты в движении, хранилища данных изображают объекты в покое. В материальных системах хранилища данных изображаются там, где объекты ожидают обработки, например в очереди. В системах обработки информации хранилища данных являются механизмом, который позволяет сохранить данные для последующих процессов.
Слияние и разветвление стрелок. В DFD стрелки могут сливаться и разветвляться, что позволяет описать декомпозицию стрелок. Каждый новый сегмент сливающейся или разветвляющейся стрелки может иметь собственное имя.
Построение диаграмм DFD
Диаграммы DFD могут быть построены с использованием традиционного структурного анализа, подобно тому, как строятся диаграммы IDEF0. Сначала строится физическая модель, отображающая текущее состояние дел. Затем эта модель преобразуется в логическую модель, которая отображает требования к существующей системе. После этого строится модель, отображающая требования к будущей системе. И наконец, строится физическая модель, на основе которой должна быть построена новая система.
Альтернативным подходом является подход, популярный при создании программного обеспечения, называемый событийным разделением (event Partitioning), в котором различные диаграммы DFD выстраивают модель системы. Во-первых, логическая модель строится как совокупность работ и документирования того, что они (эти работы) должны делать.
Затем модель окружения (environment model) описывает систему как объект, взаимодействующий с событиями из внешних сущностей. Модель окружения обычно содержит описание цели системы, одну контекстную диаграмму и список событий. Контекстная диаграмма содержит один прямоугольник работы, изображающий систему в целом, и внешние сущности, с которыми система взаимодействует.
Наконец, модель поведения (behavior model) показывает, как система обрабатывает события. Эта модель состоит из одной диаграммы, в которой каждый прямоугольник изображает каждое событие из модели окружения. Хранилища могут быть добавлены для моделирования данных, которые необходимо запоминать между событиями. Потоки добавляются для связи с другими элементами, и диаграмма проверяется с точки зрения соответствия модели окружения. Полученные диаграммы могут быть преобразованы с целью более наглядного представления системы, в частности работы на диаграммах могут быть декомпозированы.
Нумерация объектов
В DFD номер каждой работы может включать префикс, номер родительской работы (А) и номер объекта. Номер объекта - это уникальный номер работы на диаграмме. Например, работа может иметь номер А. 12.4. Уникальный номер имеют хранилища данных и внешние сущности независимо от их расположения на диаграмме. Каждое хранилище данных имеет префикс D и уникальный номер, например D5. Каждая внешняя сущность имеет префикс Е и уникальный номер, например Е5.
Наличие в диаграммах DFD элементов для описания источников, приемников и хранилищ данных позволяет более эффективно и наглядно описать процесс документооборота. Однако для описания логики взаимодействия информационных потоков более подходит IDEF3, называемая также workflow diagramming - методологией моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов. Диаграммы Workflow могут быть использованы в моделировании бизнес-процессов для анализа завершенности процедур обработки информации.
1.3 Методология IDEF3
IDEF3 является стандартом документирования технологических процессов, происходящих на предприятии, и предоставляет инструментарий для наглядного исследования и моделирования их сценариев. Сценарием (Scenario) называется описание последовательности изменений свойств объекта, в рамках рассматриваемого процесса (например, описание последовательности этапов обработки детали в цеху и изменение её свойств после прохождения каждого этапа). Исполнение каждого сценария сопровождается соответствующим документооборотом, который состоит из двух основных потоков: документов, определяющих структуру и последовательность процесса (технологических указаний, описаний стандартов и т.д.), и документов, отображающих ход его выполнения (результатов тестов и экспертиз, отчетов о браке, и т.д.). Для эффективного управления любым процессом, необходимо иметь детальное представление об его сценарии и структуре сопутствующего документооборота. Средства документирования и моделирования IDEF3 позволяют выполнять следующие задачи:
· документировать имеющиеся данные о технологии процесса, выявленные, скажем, в процессе опроса компетентных сотрудников, ответственных за организацию рассматриваемого процесса;
· определять и анализировать точки влияния потоков сопутствующего документооборота на сценарий технологических процессов;
· определять ситуации, в которых требуется принятие решения, влияющего на жизненный цикл процесса, например изменение конструктивных, технологических или эксплуатационных свойств конечного продукта;
· содействовать принятию оптимальных решений при реорганизации технологических процессов;
· разрабатывать имитационные модели технологических процессов, по принципу «КАК БУДЕТ, ЕСЛИ…».
Стандарт IDEF3 предназначен для описания бизнес-процессов нижнего уровня и содержит объекты - логические операторы, с помощью которых показывают альтернативы и места принятия решений и в бизнес-процессе, а также объекты - стрелки с помощью которых показывают временную последовательность работ в бизнес-процессе (рис. 4).
Существуют два типа диаграмм в стандарте IDEF3, представляющие описание одного и того же сценария технологического процесса в разных ракурсах.
Рис. 4. Схема бизнес-процесса в стандарте IDEF3
Диаграммы относящиеся к первому типу называются диаграммами Описания Последовательности Этапов Процесса (Process Flow Description Diagrams, PFDD), а ко второму - диаграммами Состояния Объекта в и его Трансформаций Процессе (Object State Transition Network, OSTN). Предположим, требуется описать процесс окраски детали в производственном цеху на предприятии. С помощью диаграмм PFDD документируется последовательность и описание стадий обработки детали в рамках исследуемого технологического процесса. Диаграммы OSTN используются для иллюстрации трансформаций детали, которые происходят на каждой стадии обработки.
На следующем примере, опишем, как графические средства IDEF3 позволяют документировать вышеуказанный производственный процесс окраски детали. В целом, этот процесс состоит непосредственно из самой окраски, производимой на специальном оборудовании и этапа контроля ее качества, который определяет, нужно ли деталь окрасить заново (в случае несоответствия стандартам и выявления брака) или отправить ее в дальнейшую обработку.
Рис. 5. Пример PFDD диаграммы
На рисунке 5 изображена диаграмма PFDD, являющаяся графическим отображение сценария обработки детали. Прямоугольники на диаграмме PFDD называются функциональными элементами или элементами поведения (Unit of Behavior, UOB) и обозначают событие, стадию процесса или принятие решения. Каждый UOB имеет свое имя, отображаемое в глагольном наклонении и уникальный номер. Стрелки или линии являются отображением перемещения детали между UOB_блоками в ходе процесса. Линии бывают следующих видов:
· Старшая (Precedence) - сплошная линия, связывающая UOB. Рисуется слева направо или сверху вниз;
· Отношения (Relational Link) - пунктирная линия, использующаяся для изображения связей между UOB;
· Потоки объектов (Object Flow) - стрелка с двумя наконечниками используется для описания того факта, что объект (деталь) используется в двух или более единицах работы, например, когда объект порождается в одной работе и используется в другой.
Объект, обозначенный J1 - называется перекрестком (Junction). Перекрестки используются для отображения логики взаимодействия стрелок (потоков) при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fan-out Junction) стрелок. Перекресток не может использоваться одновременно для слияния и для разветвления. При внесении перекрестка в диаграмму необходимо указать тип перекрестка. Классификация возможных типов перекрестков приведена в таблице 1.
Таблица 1
Название перекрестков |
Обозначение перекрестков |
Смысл перекрестков |
|||
Схема расхождения |
Схема схождения |
||||
«Исключающий ИЛИ» |
Только одна последующая работа запускается |
Только одна предшествующая работа должна быть завершена |
|||
«И» |
Асинхронный |
Все последующие работы запускаются |
Все предшествующие работы должны быть завершены |
||
Синхронный |
Все последующие работы запускаются одновременно |
Все предшествующие работы должны быть завершены одновременно |
|||
«ИЛИ» |
Асинхронный |
Одна или несколько последующих работ запускаются |
Одна или несколько предшествующих работ должны быть завершены |
||
Синхронный |
Одна или несколько последующих работ запускаются одновременно |
Одна или несколько предшествующих работ должны быть завершены одновременно |
Все перекрестки в PFDD диаграмме нумеруются, каждый номер имеет префикс «J». Сценарий, отображаемый на диаграмме, можно описать в следующем виде:
Деталь поступает в окрасочный цех, подготовленной к окраске. В процессе окраски наносится один слой эмали при высокой температуре. После этого, производится сушка детали, после которой начинается этап проверки качества нанесенного слоя. Если тест подтверждает недостаточное качество нанесенного слоя (недостаточную толщину, неоднородность и т.д.), то деталь заново пропускается через цех окраски. Если деталь успешно проходит контроль качества, то она отправляется в следующий цех для дальнейшей обработки.
Каждый функциональный блок UOB может иметь последовательность декомпозиций, и, следовательно, может быть детализирован с любой необходимой точностью. Под декомпозицией мы понимаем представление каждого UOB с помощью отдельной IDEF3 диаграммы. Например, мы можем декомпозировать UOB «Окрасить Деталь», представив его отдельным процессом и построив для него свою PFDD диаграмму. При этом эта диаграмма будет называться дочерней, по отношению к изображенной на рис. 5, а та, соответственно родительской. Номера UOB дочерних диаграмм имеют сквозную нумерацию, т.е., если родительский UOB имеет номер «1», то блоки UOB на его декомпозиции будут соответственно иметь номера «1.1», «1.2» и т.д. Применение принципа декомпозиции в IDEF3 позволяет структурировано описывать процессы с любым требуемым уровнем детализации.
Рис. 6. Пример OSTN диаграммы
Если диаграммы PFDD технологический процесс «С точки зрения наблюдателя», то другой класс диаграмм IDEF3 OSTN позволяет рассматривать тот же самый процесс «С точки зрения объекта». Состояния объекта (в нашем случае детали) и Изменение состояния являются ключевыми понятиями OSTN диаграммы. Состояния объекта отображаются окружностями, а их изменения направленными линиями. Каждая линия имеет ссылку на соответствующий функциональный блок UOB, в результате которого произошло отображаемое ей изменение состояния объекта.
В IDEF3 декомпозиция используется для детализации работ. Методология IDEF3 позволяет декомпозировать работу многократно, т.е. работа может иметь множество дочерних работ. Это позволяет в одной модели описать альтернативные потоки. Возможность множественной декомпозиции предъявляет дополнительные требования к нумерации работ. Так, номер работы состоит из номера родительской работы, версии декомпозиции и собственного номера работы на текущей диаграмме.
Рассмотрим процесс декомпозиции диаграмм IDEF3, включающий взаимодействие автора (аналитика) и одного или нескольких экспертов предметной области.
Перед проведением сеанса экспертизы у экспертов предметной области должны быть документированные сценарии и рамки модели, для того чтобы понять цели декомпозиции. Обычно эксперт предметной области передает аналитику текстовое описание сценария. В дополнение к этому может существовать документация, описывающая интересующие процессы. Из этой информации аналитик должен составить предварительный список работ (отглагольные существительные, обозначающие процесс) и объектов (существительные, обозначающие результат выполнения работы), которые необходимы для перечисленных работ. В некоторых случаях целесообразно создать графическую модель для представления ее эксперту предметной области.
Тип объекта ссылки |
Цель описания |
|
OBJECT |
Описывает участие важного объекта в работе |
|
GOTO |
Инструмент циклического перехода (в повторяющейся последовательности работ), возможно на текущей диаграмме, но не обязательно. Если все работы цикла присутствуют на текущей диаграмме, цикл может также изображаться стрелкой, возвращающейся на стартовую работу. GOTO может ссылаться на перекресток |
|
UOB (Unit of behaviour) |
Применяется, когда необходимо подчеркнуть множественное использование какой-либо работы, но без цикла. Например, работа «Контроль качества» может быть использована в процессе «Изготовление изделия» несколько раз, после каждой единичной операции. Обычно этот тип ссылки не используется для моделирования автоматически запускающихся работ |
|
NOTE |
Используется для документирования важной информации, относящейся к каким-либо графическим объектам на диаграмме. NOTE является альтернативой внесению текстового объекта в диаграмму |
|
ELAB (Elaboration) |
Используется для усовершенствования графиков или их более детального описания. Обычно употребляется для детального описания разветвления и слияния стрелок на перекрестках |
Поскольку разные фрагменты модели IDEF3 могут быть созданы разными группами аналитиков в разное время, IDEF3 поддерживает простую схему нумерации работ в рамках всей модели. Разные аналитики оперируют разными диапазонами номеров, работая при этом независимо.
В результате дополнения диаграмм IDEF0 диаграммами DFD и IDEF3 может быть создана смешанная модель, которая наилучшим образом описывает все стороны деятельности предприятия.
универсальный графический моделирование трикотажный процесс
2. Описание предметной области
2.1 Краткая характеристика производства трикотажных изделий
Для производства одежды применяют различные материалы, которые подразделяют на основные, составляющие детали верха и подкладки; прикладные, применяемые для создания каркаса, жесткой формы, укрепления деталей; теплоизоляционные; соединительные; фурнитуру и отделочные.
В качестве основных материалов используют ткани, трикотажные полотна, натканные, пленочные и слоистые материалы различного волокнистого состава и структуры, искусственные меха и кожи. Промышленность изготовляет в основном одежду из тканей и трикотажных полотен. По сырьевому составу их делят на хлопчатобумажные, шерстяные, шелковые, льняные, по назначению - на пальтовые, костюмные, платьевые, сорочечные, бельевые и подкладочные. К внешнему виду, гигиеническим свойствам этих материалов, стойкости к различным воздействиям предъявляют различные требования. Так, материалы, используемые для деталей верха пальто, должны иметь красивый внешний вид, достаточную стойкость к истирающим и сминающим нагрузкам; подкладочные - хорошую стойкость к истиранию, гигроскопичность, паро- и воздухонепроницаемость.
К трикотажным относят изделия, полученные из нитей (пряжи) путем машинного или ручного вязания.
Некоторые трикотажные изделия полностью вяжут на машинках (чулки, носки, платки, варежки и т.д.), другие - белье, большинство верхних трикотажных изделий, перчатки - шьют из изготовленного (связанного) на машинах трикотажного полотна.
По назначению вырабатываемой продукции трикотажную промышленность подразделяют на следующие виды производств: верхний и бельевой трикотаж, чулочно-носочные, перчаточное, техническое полотно и медицинские изделия.
Трикотажное изделие характеризует большая растяжимость и пластичность, что дает возможность достижения ощущения легкости и комфорта.
Трикотажем называется текстильное полотно или изделие, полученное путем вязания, поэтому любой трикотажный материал представляет собой систему петель, соединенных в продольном и поперечном направлениях.
Трикотажная ткань состоит из двух перпендикулярно пересекающихся систем нитей. Продольные нити называются основой, а поперечные - утком. Первичным элементом структуры трикотажа является петля. Она представляет собой пространственную кривую, форма которой влияет на свойства полотна. Форма петель разнообразна: округлая, широкая, зауженная, удлиненная.
По высоте различают петли нормальной величины, уменьшенные и увеличенные. Чем выше петля и больше распрямлена нить, тем светлее кажется полотно в результате направленного отражения света.
Петли, соединяясь друг с другом по горизонтали, образуют петельные ряды, по вертикали - петельные столбики. Расстояние между центрами или одноименными точками двух соседних петель по линии петельного ряда называется петельным шагом.
Трикотаж делят на основовязальный и кулирный. В основовязальном каждая нить образует в петельном ряду по одной петле и переходит в следующий ряд. В кулирном трикотаже каждая нить последовательно образует петли одного петельного ряда. Для образования одного петельного ряда кулирного трикотажа достаточно одной нити. Для образования петельного ряда основовязального трикотажа требуется, как правило, столько нитей, сколько петель в петельном ряду.
Кулирный и основовязальный трикотаж может быть как одинарным, так и двойным. Одинарный трикотаж вырабатывается на машинах с одной игольницей, а двойной трикотаж - на машинных с двумя игольницами.
Согласно классификации все трикотажные переплетения разделяются на главные (переплетения, имеющие простейшую структуру) и производные (сочетание нескольких одинаковых главных переплетений, взаимно ввязанных так, что между петельными столбиками одного переплетения размещаются петельные столбики другого такого же переплетения). На базе каждого из классов этих групп можно образовать рисунчатые и комбинированные переплетения (переплетения, которые состоят из переплетений нескольких классов).
Для получения ткани в простейшем случае необходимы две системы нитей (основа и уток). Трикотаж может быть связан полностью из одной нити. А так же трикотажные изделия могут быть изготовлены следующими способами:
· Раскройный
· Полурегулярный
· Регулярный
Раскройный способ состоит в том, что трикотажное полотно раскраивают, т.е. вырезают из него детали изделий по лекалам и соединяют их на швейной машине, придавая изделиям необходимую форму. По этому способу изготовляют бельевые и верхние изделия, а также большую часть перчаточных изделий. Для этого способа изготовления изделий характерны значительные отходы трикотажного полотна, достигающие 18-23% при раскрое бельевых изделий и до 25-28% при раскрое верхних изделий. Такая технология применяется для недорогих изделий в массовом производстве и бельевом трикотаже. Положительным для этого способа является возможность изготовления изделий разнообразных моделей и высокая производительность вязальных машин.
Полурегулярный способ отличается от предыдущего тем, что трикотажное полотно вяжется на кругловязальной машине в виде купонов трубчатой формы. Купоны отделяются один от другого с помощью разделительного петельного ряда так, что нижний край купона имеет цельный нераспускающийся петельный ряд, не требующий швейной обработки. Расход трикотажного полотна на изделие при полурегулярном способе изготовления на 3-5% меньше, чем при раскройном способе из-за отсутствия боковых швов и припусков на подгиб низа изделия; кроме того, меньше и время на раскрой и швейную обработку на 8-10%.
Полурегулярный способ наиболее распространен при изготовлении верхних трикотажных изделий, а также может быть использован для изготовления женского белья при наличии необходимого вязального оборудования. Изделия, изготовленные этим способом, имеют большое преимущество в достижении наилучшего прилегания и посадки изделия.
Регулярный способ изготовления изделия состоит в том, что изделия вывязываются целиком без швов или отдельные детали вяжутся по контуру, а потом сшиваются цепным стежком. Характерным для этого способа является наиболее экономное использование сырья. Однако вязание деталей изделия требует больших трудовых затрат, чем вязание полурегулярным способом. Этот способ используется при вязании верхних изделий из дорогостоящего материала.
Две последние технологии наиболее применимы в эксклюзивном мелкосерийном производстве, т.к. дают возможность достичь высокого качества изделия, максимальный ассортимент изделий и быструю сменяемость моделей.
2.2 Описание основных бизнес-процессов трикотажной фабрики (на основе диаграммы с методологией IDEF0)
Контроль качества сырья
Сырье, поступившее на склад трикотажного предприятия, оценивают по внешнему виду. Образцы сырья испытывают в лаборатории для определения физико-механических показателей. Методы испытания сырья и виды его пороков должны соответствовать указанным в действующей нормативно-технической документации.
Расфасовка сырья
После лабораторных испытаний сырье партиями поступает на цеховые склады в ящиках, коробках или другой таре. На цеховом складе сырье распаковывается и расфасовывается. Расфасованное сырье подается к вязальным машинам. Обнаруженные при расфасовке бобины с дефектной намоткой откладывают для перематывания.
Вязание полотна
Перед вязанием нити должны выдерживаться в местах хранения не менее 10 ч при нормальных климатических условиях. Полотно вяжется на машинах в соответствии с заправочными данными. Плотность вязания измеряют на машине в свободном состоянии полотна. Куски полотна из нитей одной линейной плотности вяжутся одинаковой массы (10-12 кг) с отклонениями, не превышающими 5%.
Качество полотна в процессе вязания на протяжении всей смены контролируют вязальщица и помощник мастера. Вязальщица обязана содержать машину в чистоте - ежесменно ее чистить.
Подготовка полотна к раскрою
Трикотажное полотно после отделки поступает в отделы подготовки полотна к раскрою, в которых осуществляют: прием полотна и прикладных материалов; разбраковка полотна, т.е. полотно просматривается на машине с обеих сторон для определения его качества и выявления пороков; хранение (отлеживание) полотна; подбор полотна по артикулам и ширинам; комплектование полотен в настил; подготовку трафарета; подготовку прикладных материалов и выдачу их в раскрой; расчет карты раскроя полотна для каждого настила.
Полотно в отдел подготовки подается партионно, т.е. по артикулам, цветам и расчетным ширинам. Подобранные для настила куски полотна подаются в раскройный цех вместе с картой раскроя и подготовленным трафаретом.
Обмеловка настила
Обмеловку верхнего слоя настила, или нанесение контуров раскраиваемых деталей на верхний слой настила, выполняют двумя способами: по лекалам и по трафарету.
При обмеловке по лекалам на верхнем слое настила в соответствии с зарисовкой раскладки раскладывают лекала таким образом, чтобы площадь полотна была использована наиболее рационально.
При использовании трафарета раскладываемые на нем лекала обводят по контурам, на которые затем наносят сквозные отверстия. Обмеловка по трафарету состоит в том, что на верхний слой настила накладывают трафарет и запудривают отверстия контуров лекал порошком - мелом или тальком.
Раскрой полотна
Раскрою полотна предшествует операции настилания полотна и разрезания его на секции.
Основовязаное полотно настилают вразворот или взгиб. Настилание взгиб применяют при раскрое изделий небольшими партиями. Настилание вразворот обеспечивает более экономное использование полотна по сравнению с настиланием взгиб благодаря рациональному расположению лекал изделий на большой ширине полотна; кроме того, при этом способе облегчается контроль полотна.
Настилание полотна выполняется с помощью машины и вручную. Настил полотна разрезают передвижными раскройными машинами с прямыми и дисковыми ножами и стационарными ленточными машинами.
В процессе этой операции должны быть выполнены следующие требования:
§ Полотна тканей в настиле должны располагаться свободно, без натяжения и перекосов, но и без слабины и морщин, иначе детали кроя могут быть деформированы;
§ Рисунок во всех полотнах настила должен совпадать по длине и ширине, иначе в готовом изделии нарушается симметричность рисунка;
§ Направление ворса во всех полотнах настила должно совпадать, чтобы во всех деталях готового изделия ворс был направлен в одну сторону.
Разрезание полотна - сложная и ответственная операция. Обеспечить высокое качество раскроя при разрезании настила можно только при условии выполнения следующих требований:
§ Высокая точность кроя: отклонение от контуров деталей не должны превышать см;
§ Контуры деталей не должны быть перекошены;
§ Хорошее качество реза, т.е. частота краев вырезанных деталей.
Контроль качества кроя производится по контрольным лекалам путем совмещения с ними выкроенных деталей из настила. Обычно проверяют верхнюю, нижнюю и одну-две детали из середины пачки.
Комплектование кроеных деталей
Раскроенные детали после контроля и сортировки комплектуют в пачки. При этом их просматривают, разбирают по цветам и оттенкам, подрезают в тех местах, где они не могут быть разрезаны машинами в настиле, исправляют неточности механического раскроя.
Конечным продуктом раскройного цеха является комплект, т.е. пачка деталей подобранных по артикулу полотна, цвету, оттенку и рисунку.
Скомплектованные пачки укладывают таким образом, чтобы все мелкие детали изделий и прикладные материалы были собраны в десятки и аккуратно завязаны. Пачки направляют на швейные агрегаты.
Подобные документы
Классификация бизнес-процессов, различные подходы к их моделированию и параметры качества. Методология и функциональные возможности систем моделирования бизнес-процессов. Сравнительная оценка систем ARIS и AllFusion Process Modeler 7, их преимущества.
дипломная работа [1,6 M], добавлен 11.02.2011Архитектура интегрированных информационных систем ARIS как методология моделирования бизнес-процессов. Преимущества и недостатки существующих аналогов. Выбор и обоснование типов диаграмм, используемых для описания бизнес-процесса средствами ARIS.
дипломная работа [1,8 M], добавлен 03.12.2014Моделирование информационной системы (ИС) бизнес-процессов продуктового супермаркета "Большая Ложка" на ранней стадии (фазе формирования концепции предприятия) стандартами UML. Сценарий для моделирования ИС, начальные данные и структура управления.
курсовая работа [335,5 K], добавлен 16.09.2011Обоснование, схема и описание бизнес-процесса организации. Идентификация законов распределения случайных величин. Разработка и описание моделирующего алгоритма для реализации программы имитационной модели. Разработка компьютерной программы моделирования.
курсовая работа [265,3 K], добавлен 28.07.2013История бизнес-моделирования с середины ХХ века до настоящего времени. Определение понятий "бизнес-модель" и "бизнес-моделирование". Характеристика динамики основных положений различных бизнес-моделей по мере изменения состояния конкуренции предприятия.
курсовая работа [2,2 M], добавлен 14.05.2019Особенности моделирования бизнес-процессов в стандарте IDEF0 и расчета их эффективности. Реинжиниринг процесса изготовления мыла ручной работы с соблюдением бюджета материальных затрат, экономии материалов и соответствия всем требованиям качества.
курсовая работа [1010,5 K], добавлен 17.07.2014Теоретико-методическое описание моделирования макроэкономических процессов. Модель Харрода-Домара, модель Солоу как примеры модели макроэкономической динамики. Практическое применение моделирования в планировании и управлении производством предприятия.
курсовая работа [950,4 K], добавлен 03.05.2009Создание бизнес-модели процесса выдачи потребительских кредитов. Организационное обеспечение кредитного процесса. Моделирование и документирование бизнес-процессов в программе BPwin. Построение модели AS IS. Предложение по автоматизации бизнес-процесса.
курсовая работа [401,5 K], добавлен 07.01.2012Проектирование бизнес-процессов. Выбор BPM-системы для автоматизации бизнес-процессов. Построение прототипа системы, автоматизирующей управление бизнес-процессами. Анализ программных продуктов. Матрица связанности элементов организационной структуры.
дипломная работа [3,3 M], добавлен 26.08.2017Анализ внешней и внутренней среды, экономических показателей, предприятия. Оценка его конкурентоустойчивости. Составление матрицы привлекательности рынка. Прогнозный план доходов и расходов. Моделирование бизнес-процессов функционирования дома отдыха.
курсовая работа [1,4 M], добавлен 18.03.2015