Бизнес-процесс — это логичный, последовательный, взаимосвязанный набор мероприятий, который потребляет ресурс и выдаёт конечный продукт, представляющий особую ценность для потребителя. Любой бизнес-процесс имеет вход, выход, управление и ресурсы. Бизнес-модель — визуальное описание бизнес-процессов. Целью моделирования является предоставление в доступной форме структуры организации, а также процессов, происходящих в нём, чтобы оптимизировать работу предприятия, а также предотвратить возможные ошибки, связанные с управлением компании.
Целью курсовой работы является освоение инструментария моделирования бизнес-процессов, а также овладение технологией форматирования документов в соответствии с требованиями «Положения о бакалаврской работе». Задачи курсовой работы:
? в MS Visio создать модель бизнес-процесса «Тренажерный зал» в соответствии с требованиями ГОСТ 19.701-90;
? в BPwin создать модель бизнес-процесса «Тренажерный зал» в нотациях IDEF0, IDEF3, DFD;
? в Aris создать модель бизнес-процесса «Тренажерный зал» EPC;
Системный анализ бизнес-процессов в нотации IDEF0
? форматировать пояснительную записку в MS Word.
Моделирование бизнес-процесса в соответствии с требованиями ГОСТ 19.701-90
Постановка задачи
Необходимо смоделировать бизнес-процесс создания тренажерного зала, исходя из условия задачи:
Создать алгоритм, включающий в себя следующие процессы: аренда помещения под тренажерный зал, обустройство и закупка, получение нужных документов на открытие зала, найм персонала.
Создать алгоритмы обустройства тренажерного зала и зала йоги для посещения его клиентами в дальнейшем, создать алгоритм обустройства сауны, бассейна и раздевалок для удобства клиентов. Создать подробный алгоритм покупки тренажеров в зал. Описать процесс аренды помещения под тренажерный зал.
Алгоритм процесса
Формальное описание алгоритмов осуществляют с использованием схем алгоритмов. Для их отображения существует ГОСТ 19.701-90 «Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения». Для создания диаграмм и блок-схем наиболее подходящим редактором является программа Microsoft Visio, в которой изображён представленный ниже алгоритм.
В модели, составленной в соответствии с требованиями ГОСТ 19.701-90 процесс создания тренажерного зала можно провести в четыре этапа, представленные на рисунке 1.
Рисунок 1 «Этапы открытия тренажерного зала», нулевой уровень
Рисунок 2 «Аренда помещения под тренажерный зал», первый уровень
Рисунок 3 «Обустройство и закупка», первый уровень
Понятия | IDEF0 блоки
Рисунок 4 «Получение нужных документов для открытия зала», первый уровень
Рисунок 5 «Найм персонала», первый уровень
Моделирование бизнес-процесса в нотации IDEF0, IDEF3, DFD
Методология IDEF0 — это методология функционального моделирования сложных систем, где она показана в виде набора взаимосвязанных функций, чаще всего эта методология является первым этапом изучения любой системы.
Именно в данной методологии описаны нулевой (рисунок 6) и первый (рисунок 7) уровни проектируемой модели. На нулевом уровне на входе — находится необходимость наличия помещения, исполнителем является персонал тренажерного зала, капитал, нужный для закупки и обустройства, управляется их деятельность документами, нужными для открытия тренажерного зала. В ходе деятельности получается готовый продукт — тренажерный зал.
Рисунок 6 — IDEF0 «Создание тренажерного зала», нулевой уровень
Модель IDEF3 описывает переходы объектов. IDEF3 показывает причинно-следственные связи между ситуациями и событиями в понятной эксперту форме, используя структурный метод выражения знаний о том, как функционирует система, процесс или предприятие. Декомпозицию процесса аренды помещения (рисунок 8) удобнее всего производить именно в этой нотации. В данном процессе происходят следующие действия: поиск помещения для аренды, заключение договора об аренде и оплата за аренду.
Рисунок 7 — IDEF0 «Создание тренажерного зала», первый уровень
Модель DFD или диаграмма потоков данных представляет собой иерархию функциональных процессов, связанных потоками данных. Цель такого представления- продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами. С использованием данной методологии смоделирован процесс закупки тренажеров в зал (рисунок 9,10).
В процессе закупки тренажеров в зал участвуют только два лица: владелец тренажерного зала и работник магазина, для осуществления данного процесса владельцу нужны деньги на покупку и список товаров.
В процессе закупки тренажеров в зал всю деятельность выполняет владелец тренажерного зала и работник магазина. Производятся такие процессы, как поиск нужных тренажеров в базе данных товаров, получение тренажеров владельцем и оплата покупки. Купленные тренажеры в будущем будут использоваться посетителями в основном зале для занятия пауэрлифтингом и другими видами тренировок.
Рисунок 8 — IDEF3 «Аренда помещения», второй уровень
Рисунок 9 — DFD «Закупка тренажеров в зал», второй уровень
Рисунок 10 — DFD «Закупка тренажеров в зал», второй уровень
Источник: studbooks.net
Методология функционального моделирования IDEF0
Функциональная модель системы описывает совокупность выполняемых системой функций и характеризует морфологию системы (ее строение) — состав подсистем, их взаимосвязи. Такая модель рассматривает систему как набор действий, каждое из которых преобразует некоторый объект или набор объектов.
Функциональные модели выделяют действия посредством представления в виде специального элемента — функционального блока. Блок, изображающий некоторую бизнес-функцию (англ. Activity, говорят также «действие» или «работа»), является центральным элементом нотации IDEF0 (рис. 2.1). Блок имеет четыре стороны:
- — левая — вход: входящие в левую грань стрелки изображают данные или объекты, изменяемые в ходе выполнения бизнсс-функции;
- — правая — выход: выходящие из правой грани стрелки изображают данные или объекты, появляющиеся в результате выполнения бизнсс-функции;
- — верхняя — управление: входящие в верхнюю грань стрелки изображают правила и ограничения, согласно которым выполняется бизнес-функция;
- — нижняя — механизм: входящие в нижнюю грань стрелки изображают ресурсы, необходимые для выполнения бизнес-функции, но не изменяемые ею (например, оборудование, людские ресурсы и т. п.).
Рис. 2.1. Функциональный блок в IDEF0
Взаимодействие между функциями в LDEF0 представляется в виде стрелки, которая отображает поток данных или материалов, поступающий с выхода одной функции на вход другой. В зависимости от того, с какой стороной блока связан поток, его называют соответственно входным, выходным или управляющим.
В IDEF0 реализованы три базовых принципа моделирования бизнес-процессов:
- 1) принцип функциональной декомпозиции;
- 2) принцип ограничения сложности;
- 3) принцип контекста.
В соответствии с принципом функциональной декомпозиции, сложная бизнес-функция может быть представлена в виде совокупности составляющих ее более простых функций, которые сами в свою очередь могут быть подвергнуты декомпозиции. Представляя функции графически, в виде блоков, можно как бы заглянуть внутрь блока и детально рассмотреть ее структуру и состав (рис. 2.2).
Рис. 2.2. Принцип декомпозиции в IDEF0
Согласно принципу ограничения сложности количество функциональных блоков на одной диаграмме должно быть не менее двух и не более шести. Таким образом обеспечивается разборчивость и удобочитаемость диаграмм IDEF0. Практика показывает, что соблюдение этого принципа в большинстве случаев приводит к тому, что бизнес-процессы, представленные в виде модели IDEF0, хорошо структурированы, понятны и легко поддаются анализу.
Принцип контекста состоит в том, что моделирование бизнес-процесса начинается с построения контекстной диаграммы. На этой диаграмме отображается только один блок -главная бизнес-функция моделируемой системы. При определении главной бизнес-функции необходимо всегда иметь в виду цель моделирования и точку зрения па модель. Одно и то же предприятие может быть описано по-разному, в зависимости от того, с какой точки зрения его рассматривают (сравните, например, взгляд на компанию ее генерального директора и налогового инспектора).
Контекстная диаграмма играет еще одну роль в функциональной модели. Она «фиксирует» границы моделируемой бизнес-системы, определяя то, как моделируемая система взаимодействует со своим окружением. Это достигается посредством описания стрелок, соединенных с блоком, представляющим главную бизнес-функцию.
Результатом применения IDEF0 к некоторой системе является модель этой системы, состоящая из иерархически упорядоченного набора диаграмм, документации и словарей, связанных друг с другом с помощью перекрестных ссылок. Пример модели бизнес-процесса в нотации IDEF0 приведен на рис. 2.3.
Типовой сценарий применения функционального моделирования для совершенствования деятельности компании состоит из следующих четырех шагов.
Шаг 1. Построение модели «как есть». Построение функциональной модели «как есть» позволяет четко определить, какие бизнес-процессы имеют место в компании и какие информационные объекты используются при выполнении процессов и отдельных операций.
1Ж1,иачг»»1во«»*1 цаМ1Ш1ВГ«Л. Г,
X3I MIAO UI 4ЬМк^«И IU|^e
- 1ПЗН P3OOTI
- ->азрзоо?ать! эегламент бизнес!
- -‘«ламсмг эи^ео
- -лесная
Источник: ozlib.com
Модель бизнес-процесса в IDEF0
Бизнес-процесс — это совокупность взаимосвязанных мероприятий или задач, направленных на создание определенного продукта или услуги для потребителей. Для наглядности бизнес-процессы визуализируют при помощи блок-схемы бизнес-процессов.
Бизнес-процесс характеризуется следующими показателями:
Рисунок 3 Бизнес-процесс «Заключение договора с клиентом»
Модель в IDEF0 представлена совокупностью иерархически упорядоченных и логически связанных диаграмм. Каждая диаграмма располагается на отдельном листе. Диаграммы — главные компоненты модели, все функции проектируемой системы и связи представлены как блоки и дуги.
Для разработки модели в IDEF0 использовалась программа Business Studio.
Business Studio — система визуального бизнес-моделирования, основное назначение которой — описание моделей бизнес-процессов предприятия, организационных структур, документооборота, с автоматической генерацией регламентов процессов, процедур, положений о подразделениях и должностных инструкций, доступных на каждом рабочем месте в форме HTML-навигатора или документов Microsoft Word.
Модель бизнес-процесса в IDEF0 согласно 13 варианту «Заключение договора с клиентами»
Рисунок 4 Декомпозиция «Заключение договора с клиентами»
Рисунок 5 Декомпозиция «Оценка надежности клиента для определения возможности дальнейшей работы с ним»
Рисунок 6 Декомпозиция «Подготовка договора с клиентом»
Рисунок 7 Декомпозиция «Юридический аудит договора с клиентом»
Модель бизнес-процесса в нотации еЕРС
Нотация EPC (Event-Driven Process Chain — событийная цепочка процессов) используется для описания процессов нижнего уровня. Диаграмма процесса в нотации EPC, представляет собой упорядоченную комбинацию событий и функций.
Для каждой функции могут быть определены начальные и конечные события, участники, исполнители, материальные и документальные потоки, сопровождающие её, а также проведена декомпозиция на более низкие уровни. Декомпозиция может производиться только в нотации EPC.
События переключают функции, т.е. передают управление от одной функции к другой; они могут быть также результатом выполнения функций. В отличие от функций, которые имеют некоторую продолжительность, события происходят моментально. Например, событием может быть:
Состояние внешней или внутренней среды;
Отражение факта свершившегося действия;
Отражение необходимости выполнения действия;
События являются условиями выполнения функций;
События отражают исходы выполнения функций;
Любой процесс начинается и заканчивается событием4
Конечное событие одного процесса может являться начальным событием другого процесса.
При декомпозиции процесса, расположенного на диаграмме SADT, в нотации ЕРС стрелки с диаграммы SADT на диаграмму ЕРС не переносятся.
Рисунок 8 Банк в нотации EPC
Информационная модель, реализованная с применением программного продукта Erwin Data Modeler
Информационная модель — это спецификация структуры данных и бизнес правил (правил предметной области).
На современном рынке средств разработки ИС достаточно много систем, в той или иной степени удовлетворяющих перечисленным требованиям. CASE-средства ERwin и Bpwin, разработанные фирмой PLATINUM, входят в число лучших на сегодняшний день.
Erwin — средство разработки структуры базы данных (БД). Erwin сочетает графический интерфейс Windows, инструменты для построения ER-диаграмм, редакторы для создания логического и физического описания модели данных и прозрачную поддержку ведущих реляционных СУБД и настольных баз данных.
С помощью Erwin можно создавать или проводить обратное проектирование (реинжиниринг) баз данных. Этот программный продукт — лидер среди средств моделирования баз данных и хранилищ данных. Позволяет проектировать, документировать и сопровождать базы данных различных типов. Поддерживая прямое и обратное проектирование для 20 типов СУБД, Erwin повышает качество разрабатываемой БД, производительность труда и скорость разработки.
Реализация моделирования в Erwin базируется на теории реляционных баз данных и на методологии IDEF1X.
Основные компоненты диаграммы Erwin — это сущности, атрибуты и связи. Каждая сущность является множеством подобных индивидуальных объектов, называемых экземплярами. Каждый экземпляр индивидуален и должен отличаться от всех остальных экземпляров. Построение модели данных предполагает определение сущностей и атрибутов, т. Е. необходимо определить, какая информация будет храниться в конкретной сущности или атрибуте. Если рассматривать диаграмму как графическое представление правил предметной области, то сущности и атрибуты являются существительными, а связи — глаголами.
Логический уровень — это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире. Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами. Логическая модель данных может быть построена на основе другой логической модели, например на основе модели процессов.
Рисунок 8 Логический уровень
Физический уровень представляет физическую модель данных, которая зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация о всех объектах БД.
Рисунок 9 Физический уровень
Источник: studwood.net
