Файл: Разработка регламента выполнения процесса «Предоставление рекламных услуг.pdf

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 25.04.2023

Просмотров: 298

Скачиваний: 2

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

Также из наиболее популярных используемых можно отметить автоматическую генерацию отчетов на основе построенных моделей. Отчеты содержат всю информацию по проекту и отражают его текущее состояние.

Oracle Designer подойдет компаниям, в которых используются другие продукты от Oracle. Система требует специализированного и дорогостоящего обучения для специалистов, которые будут с ней работать. Тем не менее правильно настроенная инфраструктура и квалифицированный персонал могут достигать с этой системой невиданных высот.

ARIS. Интегрированное средство моделирования бизнес-процессов от компании IDS Scheer AG. Программный пакет объединяет в себе разнообразные методы моделирования и анализа систем. В первую очередь это средство описания, анализа, оптимизации и документирования бизнес-процессов. Достоинством данной системы является возможность построения одной и той же модели с использованием различных сочетаний методик. Такой подход позволяет работать с системой специалистам, имеющим различную теоретическую базу. Методика моделирования ARIS построена на разработанной Августом Шером теории построения интеграционных информационных систем, которая определяет принципы построения моделей и отражающих различные аспекты исследуемой системы факторах. Выделяют следующие модели:

  • Организационные.
  • Функциональные.
  • Информационные.
  • Модели управления.

Для построения перечисленных типов моделей используются как собственные методы моделирования ARIS, так и различные известные языки и методы, в частности, ER-модели и UML-модели. В процессе моделирования деятельности предприятия, каждый аспект деятельности рассматривается отдельно. После детальной проработки каждого из них строится интегрированная модель, отражающая связи между аспектами.

Модели в системе ARIS представляют собой диаграммы, элементами в которых являются разнообразные объекты: функция, событие, документ, структурное подразделение, и т.п. Между объектами устанавливаются различные связи. Каждому объекту соответствует определенный набор атрибутов, которые позволяют назначать дополнительную информацию о конкретном объекте. Значения атрибутов могут использоваться при имитационном моделировании или для проведения стоимостного анализа. Таким образом по результатам выполнения этого этапа возникает набор взаимосвязанных моделей, представляющих собой исходный материал для дальнейшего анализа.

Стоит также отметить несколько особенностей системы ARIS:


  • Основная бизнес-модель системы - eEPC[2]. По существу, модель eEPC расширяет возможности IDEF0, IDEF3 и DFD.
  • в системе есть внутренняя база данных, которая позволяет проверять модель на ошибки, выполнять поиск противоречий и проверить целостность общей картины
  • ARIS – единственная система, которая ориентирована на описание бизнеса с применением одновременно различных техник. Данный факт помогает оценить проектируемую модель со всех сторон.

Система ARIS из-за своих особенностей может отлично подойти большому бизнесу, но для малых проектов она не годится.

В этом параграфе мы рассмотрели три самых распространенных на мой взгляд пакета для моделирования. У каждого из них есть свои преимущества и свои недостатки. Чтобы определится с выбором пакета для наших нужд необходимо также рассмотреть методологии, по которым мы будем выполнять построение модели бизнес-процесса.

2.1 Выбор методологии

В предыдущем параграфе мы рассмотрели три самых распространенных на мой взгляд пакета для моделирования. У каждого из них есть свои преимущества и свои недостатки. Чтобы определится с выбором пакета для наших нужд необходимо также рассмотреть методологии, по которым мы будем выполнять построение модели бизнес-процесса.

Основными методологиями, используемыми в настоящее время для построения бизнес-моделей, являются следующие:

  • IDEF0;
  • IDEF3:
  • DFD

Рассмотрим эти стандарты поближе и раскроем возможности каждого их них для упрощения выбора способа описания, необходимого именно для нас.

IDEF0 – методология функционального моделирования и графическая нотация, предназначенная для графического представления и описания бизнес-процессов. Стандарт был разработан в 1981 году в США. Его разработали специально для автоматизации промышленных предприятий. Разработчикам программного обеспечения не хватало новых методов анализа бизнес-процессов и поэтому они разработали новую методологию IDEF0, для которой применялись новые нотации[3].

Функциональная модель IDEF0 состоит из блоков, каждый из которых является неким «черным ящиком», обозначающим процесс. Блоки имеют три входа и один выход из которых рисуются стрелки - связи. Связи делят на 4 группы:

  • Входящие (Input) – вводные, необходимые для начала процесса
  • Управление (Control) – механизмы управления (Инструкции, приложения, документация и пр.)
  • Механизм (Mechanism) – ресурсы, которые используются для протекания процесса (Люди, оборудование и пр.)
  • Исходящие (Output) – вывод результата процесса, выходной продукт

Важно также разделять Входящие от Механизма. Например, работника нельзя относить к входящим, так как он является механизмом для выполнения процесса. Как правило подобного рода ошибки могут возникать при применении модели IDEF0 для описания процессов, не связанных с программированием и разработкой программного обеспечения. Это связанно с тем, что изначально он разрабатывался именно для разработки программного обеспечения автоматизации производства.

Стрелки должны быть подписаны при помощи имен существительных, так как они обозначают сущности (Заказ, план, шкаф, работник и т.п.). В свою очередь блоки подписываются глаголами из-за обозначения выполняемой работы, процесса (Разработать, изменить, добавить и т.п.). Пример подобной модели показан на рисунке ниже на Ричунке 1:

Рисунок 1

IDEF0 является простым и эффективным языком описания и наглядной демонстрации процессов. Он продуман и лаконичен, что делает его использование достаточно простым для любого специалиста. Как и любой хороший инструмент он должен быть использован своевременно и уместно.

IDEF3. – методология описания процессов, с помощью которой описывается «сценарий» бизнес-процесса. В ходе описания системы эксперт может представить положение вещей как упорядоченную последовательность событий, в которой происходит описание объектов, имеющих к ней непосредственное отношение. Если в IDEF0 мы разбирали описание самого процесса, то в IDEF3 разбирается последовательность действий или подпроцессов анализируемой системы. Также стоит отметить, что язык не имеет жестких синтаксических ограничений. Этот факт позволяет производить описание неполноценных или нецелостных систем.

Основным структурным элементом является действие, или как принято его назвать в терминологии «Unit of Work» (единица работы). Действие в нём описывается глаголом или отглагольным существительным.

Пример такого блока можно увидеть на рисунке 2.

Рисунок 2

В центре идет описание самого действия. В левом нижнем углу значится его номер.

Связи между блоками реализованы стрелками. Они всегда являются однонаправленными и могут начинаться или заканчиваться на любой стороне блока, который обозначает действие. Принято, что стрелки начинаются на левой стороне блока, а заканчиваются на правой. Но это правило не обязательно к выполнению.

Существует 3 вида связей:

  • Временное предшествование – исходное действие должно завершится прежде, чем конечное действие сможет начаться
  • Объектный поток – выход исходного действия является входом конечного действия. Важно помнить, что исходное действие должно завершится прежде, чем конечное действие сможет начаться.
  • Нечеткое отношение – вид взаимодействия между исходным и конечным действиями задается аналитиком отдельно для каждого случая использования такого отношения.

Графическое изображение этих связей можно увидеть на рисунке 3

Рисунок 3

Если для связи типа «временное предшествование» всё довольно просто, то с двумя другими стоит внести пояснения.

Объектный поток – тип связи, используемый для связи двух блоков действий, в случае если «принимающий» блок может быть выполнен только при наличии объекта от «отдающего» блока. Например, действие «Оплатить счёт» не может начаться без предоставления счета от действия «Получить счёт».

Нечеткое отношение – вид связи, который используется для отношений между блоками в случае невозможности применения предшественных или объективных видов связи. Значение такой связи должно быть определено дополнительно, поскольку нет четких ограничений.

Соединения. В различных сценариях работы встает необходимость в обеспечении соединении одного действия сразу с несколькими последующими. И наоборот, несколько действий необходимо соединить с одним конечным. Всего выделяют три типа соединений:

  • И (AND, &) – каждое конечное действие обязательно инициируется или каждое исходное действие должно завершится перед выполнением инициируемого.
  • ИЛИ (OR, O) – хотя бы одно конечное действие инициируется или хотя бы одно из исходных действий должно завершится.
  • Исключительное ИЛИ (XOR, X) - одно и только одно конечное действие инициируется или одно и только одно исходное действие должно завершится.

Как можно видеть из формулировок этих типов, каждый из них можно разбить на два подвида, в зависимости от направления потока:

  • Разворачивающее
  • Сворачивающее

Рассмотренные выше типы и описания к ним справедливы для асинхронных соединений. В таких соединениях нет условия, что действия, выполняемые параллельно, должны завершаться или инициироваться одновременно. Другими словами, действия будут выполнены синхронно. Для описания таких связей необходимо использовать несколько иные формулировки типов. Ниже приведем их:

  • И (AND, &) – все действия начнутся или завершатся одновременно.
  • ИЛИ (OR, O) – одно и более действий начнутся или закончатся одновременно.
  • Исключительное ИЛИ (XOR, X) – Одновременное начало или окончание действий невозможно

Следует также помнить, что синхронное начало нескольких действий не всегда должно завершаться такой же синхронной связью к следующему действию. Ситуации могут быть разными, поэтому разработчик волен поступать в соответствии с требованиями заказчика.


Также существует понятие «парности» соединений. Оно гласит, что все разворачивающиеся соединения на построенной диаграмме должны оканчиваться сворачивающимися. Совсем не обязательно чтобы соединения были одного типа. Допускаются различные комбинации, главное, чтобы они соответствовали здравому смыслу. Пример такой связи можно увидеть на рисунке 4.

На рисунке выше мы можем наблюдать диаграмму действий оператора фрезерного станка при обнаружении неисправности. На рисунке мы можем видеть два соединения:

  • И (J7)
  • ИЛИ (J8)

При обнаружении неисправности оператор обязательно инициирует все три действия, но может оповещать мастера уже при завершении одного из них.

Рисунок 4

IDEF3 хорошо приспособлен для сбора данных, которые требуются для проведения структурного анализа процесса в целом. Кроме того, методология позволяет производить стоимостный анализ моделируемой системы, что может быть очень полезным дополнением.

DFD. Диаграммы потоков DFD[4] во многом схожи с IDEF0 и моделируют систему как набор действий, которые соединяются между собой стрелками. Но в отличие от IDEF0, диаграммы потоков данных содержат в себе еще два новых типа объектов:

  • Хранилища данных.
  • Внешние сущности.

Эти два объекта показывают реализацию связи со внешними частями системы, которые не описаны в диаграмме. Кроме того, таким же способом может быть реализована связь с другими системами.

Стрелки в DFD показывают, как данные (или объекты) перемещаются по системе от одного действия к другому. В таком представлении потока данных мы можем легко найти пути движения данных все точки хранения данных (или объектов), их источников и потребителей.

Функциональные блоки моделируют функцию, преобразующую входящий материал в готовую продукцию. Изображаются как прямоугольник с закругленными краями. Важным отличием от IDEF0 является отсутствие входов для «управления» и «механизмов». В некоторых интерпретациях нотации DFD Гейна-Сарсона данные виды входов могут моделироваться как ресурсы и изображаются в нижней части функционального блока.

Внешние сущности обеспечивают необходимые входы для системы и являются приемниками для её выходов (поставщики и потребители). Обозначаются как прямоугольник с описанием сущности. Сущность описывается существительным. Такие прямоугольники обычно размещают по краям диаграммы. Одна и та же сущность, может быть как поставщиком, так и потребителем одновременно. Также, для удобства, допускается размещение нескольких блоков с одной и той же сущностью. Такой ход позволяет избежать появления стрелок, идущих через всю диаграмму, и делает представление более наглядным.