Моделирование бизнес-процесс

Размещено на http://www.allbest.ru/

Введение

Каждое предприятие имеет свою организационную структуру, работники которой выполняют определенную работу. Но если задуматься, то не все осознают, как правильно следует выполнять работу. Это приводит к уменьшению эффективности труда, и к банкротству. Чтобы это предотвратить применяют моделирование бизнес-процессов.

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

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

1. Описание предметной области, постановка задачи исследования

В качестве предметной области будет рассматриваться частное предприятие «Пиццерия». Первым этапом исследования станет исследование основных тенденций на рынке и описание работы предприятия.

Организовывая работу общепита, в данном случае пиццерии, нужно проанализировать количество посетителей и определить время наибольшей загруженности персонала и оборудования пиццерии. Резкий рост клиентов, обычно, наблюдается в период с 18:00 до 21:00 в будние дни, когда люди едут с работы, и с 12:00 до 20:00 в выходные и праздничные дни, а также с 12:00 до 14:00 в обеденное время.

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

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

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

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

Далее следует подробнее рассмотреть работу предприятия.

«Пиццерия» осуществляет обслуживание клиентов:

- Проведение детских праздников;

- Обслуживание клиентов в обеденное время, в праздники, и любые будние дни.

В помещении пиццерии 20 посадочных мест.3 четырёхместных столика и 4 двуместных. В пиццерии самообслуживание. Ежедневный персонал насчитывает три человека: кассир, человек занимающийся тестом (заготовка теста, изготовление заготовок на пиццу и лепёшек к салатам и горячим блюдам) и приготовлением салатов и горячих блюд, т. е., основной повар. Также пиццейола, который занимается непосредственным приготовлением и подачей пиццы.

В обязанности кассира входит:

- Приветствие клиента и предоставление туалетных услуг;

- Если есть какие-либо трудности с исправность сан. узла, сообщить об этом администрации и устранить неполадки;

- Принятие заказа пиццы, обсуждение с клиентом его предпочтений. Если ассортимент данной пиццерии не может удовлетворить клиента посоветовать клиенту др. подобные заведения где его потребность могли бы удовлетворить, на этом закончить обслуживание;

- Если клиента все устраивает, то оформить заказ, произвести расчет по удобной для клиента системе (наличной и безналичной) и передать заказ на кухню;

- Сделать напитки и сообщить о готовности заказа по громкоговорителю.

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

2. Обзор и выбор существующих методов моделирования бизнес-процессов

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

Использование бизнес-процессов способствует внедрению процессно-ориентированного подхода к управлению на предприятии. При этом, описывая или моделируя существующие процессы с целью их более глубокого понимания можно обнаружить и устранить существующие недостатки (выполнить оптимизацию бизнес-процессов). Если же организацию требует кардинальных изменений необходимо разработать программу реинжиниринга бизнес-процессов и внедрить ее в предприятие.

Модель бизнеса любой компании состоит из совокупности отдельных бизнес-процессов, и от того, насколько они эффективны, зависит успех бизнеса в целом. В организациях, построенных по функциональному принципу, работники наделены ответственностью за деятельность подразделений, но никто из них не несет ответственности за то, чтобы процессы были качественно и своевременно выполненные в целом.

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

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

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

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

Моделирование и оптимизация бизнес-процессов организации имеет следующие преимущества:

- Сокращение расходов, продолжительности и количества ошибок в каждом из проанализированных процессов;

- Формирование у работников компании и руководителей четкого понимания того как, когда, кто и что должен делать для достижения поставленных целей;

- Интегрирования со стратегией компании и ключевыми показателями эффективности (KPIs);

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

- Возможность подготовиться к эффективному и обоснованному организационного редизайна;

- Рост управляемости компании;

- Улучшение взаимодействия между сотрудниками и подразделениями компании;

- Приближение к сертификации по стандартам ISO:9000.

2.1 Стандарт DFD

DFD (Data Flow Diagramming) - это стандарт моделирования, в котором система представляется в виде сети работ, соединенных между собой объектами, взаимодействующими с результатами данных работ. Сфера применения DFD находится в области моделирования информационных потоков организации. В этой нотации моделируется не последовательность работ, а именно потоки информации (данных) между работами и объектами, которые используют, хранят или "рождают" эти данные.

В соответствии с DFD методологией, модель системы определяется как иерархия диаграмм потоков данных, описывающих процессы преобразования информации от момента ее ввода в систему до выдачи конечному пользователю. Диаграммы верхних уровней иерархии - контекстные диаграммы, задают границы модели, определяя её окружение (внешние входы и выходы) и основные рассматриваемые процессы. Контекстные диаграммы детализируются при помощи диаграмм следующих уровней.

Основными элементами диаграмм DFD диаграмм потоков данных являются:

- Внешние сущности;

- Процессы;

- Накопители данных;

- Потоки данных.

Под внешней сущностью (External Entity) понимается материальный объект, являющийся источником или приемником информации. В качестве внешней сущности на DFD диаграмме могут выступать заказчики, поставщики, клиенты, склад, банк и другие. Определение некоторого объекта в качестве внешней сущности указывает на то, что он находится за пределами границ анализируемой информационной системы.

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

Номер процесса служит для его идентификации. В поле имени вводится наименование процесса в виде предложения с глаголом в неопределенной форме (вычислить, рассчитать, проверить, определить, создать, получить) и поясняющими существительными, например: «Напечатать адрес получателя», «Акцептовать счет». Информация в нижнем поле символа процесса указывает, какое подразделение организации, сотрудник, программа или аппаратное устройство выполняет данный процесс. Если такое поле отсутствует, то подобная информация может быть указана в текстовом примечании. В отличие от IDEF0 диаграмм, речь о которых будет идти далее, в DFD диаграммах не используются стрелки управления для обозначения правил выполнения действия и стрелки механизмов для обозначения требуемых ресурсов.

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

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

Поток данных определяет информацию, передаваемую через некоторое соединение (кабель, почтовая связь, курьер) от источника к приемнику. На DFD диаграммах потоки данных изображаются линиями со стрелками, показывающими их направление. Каждому потоку данных присваивается имя, отражающее его содержание.

В DFD используются следующие типы объектов:

- Работа (activity) - синоним работе в IDEF0 и IDEF3;

- Внешняя сущность (external entity)- объекты-источники/получатели информации/данных, изменяемых или используемых в данной функции;

- Стрелка (data flow) - обозначение потока информации (данных);

- Data store (хранилище данных) - любой механизм или абстракция (например, запись в базе данных), в которой хранятся данные.

Потоки данных между работами в DFD возможны не только опосредованно, через хранилища данных, но и непосредственно между работами, если данные не поступают сначала в хранилище.

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

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

2.2 Стандарт IDEF0

2.2.1 История возникновения стандарта IDEF0

Стремление ВВС США оказать помощь аэрокосмической промышленности в сокращении затрат и времени на модернизацию производства отражено во многих программах модернизации технологии (так называемых "Tech.Mod" - программах). Подобная задача, но в более широком, "индустриальном", плане, чем у других отдельных компаний, поставлена перед программой ICAM. Целью программы ICAM была разработка "основных подсистем общего назначения", которые могут использоваться большим числом компаний для достижения значительного прогресса в промышленности.

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

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

Для разработки "архитектуры производства" нужен был язык, с помощью которого можно описывать функционирование современной аэрокосмической промышленности. В начале работы над программой ICAM ВВС выпустили "Лист предложений", касающихся построения архитектуры. В качестве выразительного языка был выбран "Метод блочного моделирования" (в котором "блок" определен как производственная ячейка или функциональная единица). Для успешного применения язык должен удовлетворять следующим критериям:

- Так как целью архитектуры является описание производства, язык должен быть в состоянии выражать производственные операции естественным и несложным образом;

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

- Поскольку моделируемый субъект является весьма обширным и сложным, язык должен быть кратким, и обеспечивать простой и быстрый поиск интересующих деталей;

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

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

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

ВВС США в качестве методологии блочного моделирования выбрали методологию SADT (Structured Analyas and Design Technique), разработанную в начале семидесятых годов. Основные элементы этой методологии, использованные в программе ICAM, позже получили название "IDEF0".

2.2.2 Основные концепции IDEF0

IDEF0-методология основана на следующих концепциях:

- Графическое представление блочного моделирования. Графика "блоков и дуг" IDEF0-диаграммы отображают производственную операцию в виде блока, а интерфейсы входа/выхода в/из операции представляются дугами, соответственно входящими в блок или выходящими из него. Для того чтобы иметь возможность описывать производственные операции, существующие в реальности, было предложено описывать взаимодействие блоков друг с другом посредством интерфейсных дуг, выражающих "ограничения", которые в свою очередь определяют, когда и каким образом операции выполняются и управляются;

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

- Передача информации. В IDEF существует ряд средств, разработанных для улучшения передачи информации:

- диаграммы, основанные на очень простой графике блоков и дуг;

- метки на естественном языке для описания блоков и дуг, а также глоссарий и сопроводительный текст для определения точного значения элементов диаграммы;

- постепенное представление деталей, при котором на верхнем уровне иерархии показаны основные функции, а на следующих уровнях происходит их более подробное уточнение;

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

- Строгость и точность. Выполнение правил IDEF0 требует достаточной строгости и точности, чтобы удовлетворить принципам архитектуры ICAM, не накладывая в то же время чрезмерных ограничений на аналитика. Правила IDEF включают:

- ограничение количества деталей на каждом уровне (правило 3-6 блоков);

- ограниченный контекст (без пропусков, но и без дополнительных деталей, выходящих за рамки рассмотрения);

- синтаксические правила для графики (блоков и дуг);

- связность интерфейса диаграмм (номера узлов, номера блоков, С - номера);

- связность структуры данных (ICOM-коды и использование туннельных дуг);

- уникальность меток и наименований (отсутствие повторяющихся имен);

- ограничения на ветвление дуг данных (метки для ограничений потоков данных на ветвях);

- разделение входов и управлений (правило определения роли данных);

- требования к меткам дуг данных (правила минимальных меток);

- минимальное управление для функций (для каждой функции нужна, по крайней мере, одна управляющая дуга);

- цель и точка зрения (у каждой модели есть цель и точка зрения).

- Методология. Пошаговые процедуры обеспечивают моделирование, рецензирование и решение задач интеграции;

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

2.2.3 Графика блочного моделирования

Методология IDEF0 может использоваться для моделирования широкого круга систем, где под системой понимается любая комбинация средств аппаратного и программного обеспечения, а также людей. При создании новых систем IDEF0 может вначале применяться для определения требований и функций, а затем для разработки системы, которая удовлетворяет этим требованиям и реализует эти функции. Для уже существующих систем IDEF0 может быть использована для анализа функций, выполняемых системой, а также для указания механизмов, посредством которых они осуществляются. Результатом применения методологии IDEF0 является модель. Модель состоит из диаграмм, фрагментов текста и глоссария, которые имеют ссылки друг на друга. Диаграммы - главные компоненты модели. На диаграммах все функции производственной системы и интерфейсы представлены как блоки (функции) и дуги (интерфейсы). Место соединения дуги с блоком определяет тип интерфейса. Управляющие производством данные входят в блок сверху, в то время как материалы или информация, которые подвергаются производственной операции, показаны в левой стороны блока, результаты выхода показаны с правой стороны. Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей в блок снизу (рис. 2.1).

Рис. 2.1 - Функциональный блок и интерфейсные дуги:

Блоки и дуги в IDEF0-модели используются для представления связей между несколькими подфункциями на диаграмме, описывающей более общую функцию.

Эта диаграмма является "подчиненной" диаграммой и показывает конкретные интерфейсы, управляющие каждой подфункцией, а также источники и адресаты этих интерфейсов (см. рис. 2.2).

Рис. 2.2 - Диаграмма, демонстрирующая ограничения на выполнение функций:

Здесь термин "ограничение" означает, что функция использует материальные объекты или информацию, изображаемую входящей в блок и, следовательно, ограничена в своем действии зависимостью от интерфейсов, функция не может выполняться, пока не обеспечено содержание интерфейсных дуг, а вариант действия, в соответствии с которым работает функция, зависит от конкретного содержания интерфейсных дуг (объем, количество и т. д.).

2.2.4 Декомпозиция моделей IDEF0

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

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

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

Затем блок, который представляет систему в качестве единого модуля, детализируется на другой диаграмме с помощью нескольких блоков, соединенных интерфейсными дугами. Эти блоки представляют основные подфункции (подмодули) единого исходного модуля. Данная декомпозиция выявляет полный набор подмодулей, каждый из которых представлен как блок, границы которого определены интерфейсными дугами.

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

Рис. 2.3 - Структура IDEF0-модели:

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

Таким образом, методология IDEF0 описывает имеющиеся бизнес - процессы с точки зрения управления, использования ресурсов.

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

2.3 Стандарт IDEF3

2.3.1 Описание стандарта IDEF3

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

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

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

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

Для эффективного управления любым процессом, необходимо иметь детальное представление о его сценарии и структуре сопутствующего документооборота.

Средства документирования и моделирования IDEF3 позволяют выполнять следующие задачи:

- Документировать имеющиеся данные о технологии выполнения процесса, выявленные, в процессе опроса специалистов предметной области, ответственных за организацию рассматриваемого процесса или участвующих в нем;

- Анализировать существующие процессы и разрабатывать новые;

- Определять и анализировать точки влияния потоков сопутствующего документооборота на сценарий технологических процессов;

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

- Содействовать принятию оптимальных решений при реорганизации процессов;

- Разрабатывать имитационные модели технологических процессов, по принципу "как будет, если...".

2.3.2 IDEF3-диаграмма

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

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

2.4 Стандарт BPMN

BPMN - графическая нотация для моделирования бизнес-процессов. BPMN изначально был разработан консорциумом BPMI, а на сегодняшний день поддерживается OMG после того, как эти две организации объединились. Основная цель BPMN - поддержка нотации, которая одинаково будет пониматься всеми участниками бизнеса, от бизнес-аналитиков, которые разрабатывают эскизы процессов, разработчиков, которые реализуются технологию для выполнения этих процессов, и до бизнесменов, менеджеров, которые будут управлять и наблюдать за процессами. Таким образом, отмечает официальная спецификация, BPMN - это «мост» между этапами разработки и реализации бизнес-процессов. В отличие от многих других спецификаций, BPMN разрабатывался исключительно для описания бизнес-процессов и поэтому, по сути, поддерживает лишь один тип диаграмм - диаграммы бизнес-процессов. К.Е. Самуйлов подчеркивает, что BPMN, являясь графической нотацией «третьей волны» моделирования бизнес-процессов, во многих отношениях превосходит традиционные нотации.

Он позволяет моделировать взаимодействие внешние и внутренние бизнес-процессы компании, поддерживает механизмы моделирования передачи сообщений и обработки исключительных ситуаций. Другой не менее важной целью является поддержка визуализации в бизнес-нотации XML-языков, ориентированных на выполнение бизнес-процессов (например, BPEL).

OMG позиционирует стандарт как вобравший в себя все лучшие идеи, концепции и опыт других нотаций моделирования процессов, таких как ML Activity Diagram, UML EDOC Business Processes, IDEF, ebXML BPSS, Activity-Decision Flow (ADF) Diagram, RosettaNet, LOVeM, and Event-Process Chains. С одной стороны, BPMN разработана как простой и понятный механизм моделирования процессов, с другой стороны, спецификация должна быть способна обеспечить описание всей полноты и сложности бизнес-процесса, поэтому все графические элементы BPMN разбиты в упорядоченную иерархию:

- Flow Objects (объекты схемы, объекты потока управления) - основные графические элементы, которые описывают поведение бизнес-процесса. Включают три элемента;

- Event (Событие) означает нечто, которое «происходит» по время процесса. События изображаются окружностью с рисунком в центре для выделения отдельных подтипов.

В процессе можно выделить:

- Начальные (start) события - указывают на начало процесса;

- Промежуточные (intermediate) события - указывают, что что-то произошло где-то между началом и окончанием процесса;

- Завершающие (end) события - указывают на завершение процесса.

В стандарте BPMN 1.2 события делили также на две группы: события генерации и обработки. События обработки возвращают результат. К таким событиям относятся все завершающие и некоторые промежуточные события. В BPMN 2.0 группировка усложнилась и промежуточные события стали разделять для разных типов и прерываний.

Activity (Действие) - это работа, которая выполняется в процессе. Это исполняемый элемент BPMN-диаграммы. Действие может стать атомарным или составным. Определено 3 типа действий:

- Задача (task) это атомарное действие в потоке процесса. Задача используется не может детализован. В этом случае задачи выполняет пользователь или приложение. Отдельно стоит выделить задачи, решаемые с привлечением людей. BPMN выделяет два типа таких задач: ручные (manual task) и пользовательские (user task). Пользовательская задача исполняется и управляется в среде бизнес-процесса, например, это некоторое действие пользователя для реализации БП с помощью ПО, а ручная задача не контролируется системами управления бизнес-процессами. Это может дать, например, установка техническим персоналом телефона для клиента. Задача изображается прямоугольником со скругленными краями;

- Под-процесс (sub-process) - действие, которое может быть детализировано на другие действия, события, логические операторы и потоки управления. В старых версиях BPMN вместо подпроцесса выделяли Транзакцию (transaction), однако сейчас она рассматривается как специализированный тип подпроцесса. Задачи и подпроцессы могут быть снабжены определенными маркерами, указывающими некоторые характеристики их выполнения;

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

- Вызывающее действие (call activity) позволяет включать повторно используемые глобальные задачи и процессы в диаграмму и идентифицируют точку их входа в процесс. Изображается прямоугольником со скругленными краями и толстой линией границы;

- Gateways (Логические операторы) необходимы для контроля над объединением и разветвлением потоков управления процессами. Прямой перевод слова как «ворота, шлюз» предполагает наличие некоего шлюзового механизма, который разрешает или не разрешает потоку управления проходить через себя, при этом поток может быть как разделен на альтернативные ветви, так и альтернативные ветви могут объединиться. Логические операторы определяют все типы поведения потока с условиями включения, исключения, сложными условиями, объединениями и разветвлениями. Логический оператор изображается «алмазом», внутри которого изображается тип операции;

- Исключающий логический оператор (exclusive gateway, оператор исключающего «ИЛИ») применяется для создания альтернативных потоков процесса или для их объединения. Это базовый способ разделения/объединения потока процесса. При разделении может быть выбрана только одна ветвь, при объединении оператор ожидает завершения любой их входящих ветвей. Этот оператор может помечаться знаком «Х» в центре «алмаза». В случае, если ни одно из условий оператора не находится в состоянии «истина», выполнение может быть передано по ветви, определенной разработчиком «по умолчанию»;

- Включающий логический оператор (inclusive gateway, оператор включающего «ИЛИ») применяется для создания одного или нескольких альтернативных параллельных путей в потоке процесса. В отличие от исключающего оператора, все условия входа в оператор должны быть выполнены (все входящие ветви должны быть завершены). Изображается знаком окружности «О» в центре «алмаза». Ветвь по умолчанию создается для аналогичных с исключающим оператором условий.

Параллельный логический оператор (оператор «И») используется для синхронизации и создания альтернативных потоков. Изображается знаком «+». Параллельные потоки создаются без какой-либо проверки условий. При объединении потоков оператор ожидает завершения всех входящих ветвей перед тем как активировать исходящую:

- Сложный логический оператор (complex gateway) используется для моделирования сложных ситуаций синхронизации. Например, для активации исходящего потока оператор может потребовать завершения трех из пяти входящих ветвей. Использование этого оператора нежелательно, так как оно затрудняет понимание диаграммы;

- Событийный логический оператор (event-based gateway) используется для ветвления потока процесса на основе «срабатывания» определенных событий, в отличие от вычисления условных выражений с использованием данных процесса (как в вышеописанных операторах). Например, компания может ожидать ответа заказчика. Если он скажет «Да» - нужно будет провести один комплекс действий, а в случае «Нет» - совершенно другой. Ответ заказчика и идентификация сообщения определяют путь процесса, поэтому прием сообщения может быть смоделирован при помощи промежуточного события-сообщения. Вдобавок, определенный набор действий можно инициировать здесь по таймеру, если, например, клиент не ответил вовремя. Этот оператор обязан включать два и более исходящих потоков и не должен содержать условий перехода: исходящие потоки указывают на события, которые являются частью событийного оператора или на обработчики сообщений. Поток управления передается на то событие, что произошло раньше. Этот оператор изображается как составное промежуточное событие. Существуют еще и исключающий и параллельный событийные логические операторы, которые используются для создания и запуска отдельных экземпляров процесса;

- Исключающий событийный логический оператор (exclusive event-based gateway) создает экземпляр процесса, если наступает каждое из следующих за ним событий. Такой процесс или не должен иметь начального событий, а логический оператор не должен иметь входящего потока управления, или входящий поток управления приходит от обычного начального события. Изображается как составное начальное событие;

- Параллельный событийный логический оператор (parallel event-based gateway) создает экземпляр процесса при наступлении всех последующих событий. При этом первое событие инициирует процесс, но наступление остальных событий также необходимо для нормального завершения процесса. Оператор изображается как параллельное составное начальное событие.

Data (Данные) предоставляют процессу объекты, которые могут создаваться, использоваться и обрабатываться в ходе выполнения процесса:

- Data Objects (Объекты данных) предоставляют информацию, которая обрабатывается или производиться действиями. Объекты данных могут быть представлены как единичными экземплярами, так и коллекциями. Изображаются в виде пустого листка или листка с тремя чертами для коллекций;

- Data inputs (Входные данные) предоставляют данные, подающиеся на вход процесса. Изображается в виде листочка с неокрашенной стрелкой;

- Properties (Свойства) определяют некоторые признаки элементов потока управления: процессов, действий, событий. Не видны на диаграмме;

- Data outputs (Выходные данные) представляют собой результат выполнения процесса. Изображаются в виде листочка с окрашенной стрелкой;

- Data Stores (Хранилища данных) предоставляют механизм получения и добавления данных, которые будут храниться вне зависимости от жизни процесса. Изображаются значком базы данных (жесткого диска).

Connecting Objects (Соединяющие объекты) определяют четыре способа взаимодействия объектов потоков друг с другом и с другими элементами:

- Sequence Flow (Поток управления) показывает порядок работы объектов в бизнес процессе или в процессе хореографии. Каждый поток управления имеет только один источник и только одну цель. Источником и целью могут выступать только: события, действия, действия хореографии, логические операторы. Изображается сплошной линией с закрашенной стрелкой на конце. Кроме того, для потока управления может быть определено условие, показывающее, что поток будет выполнен, если будет выполнено определенное условие. Условие обычно используется, когда источник поток - логическое оператор или какое-либо действие. Поток управления с условием, исходящий из действия, обязан начинаться со значка «алмаза», при этом действие должно содержать как минимум еще один безусловный исходящий поток управления. Поток управления с условием, исходящий из логического оператора, значка «алмаза» не содержит, а логический оператор не должен быть параллельным или событийным. Поток управления может быть определенным «по умолчанию» для включающих, исключающих, сложных логических операторов или действий. Он имеет значок «слэш» в начале стрелки;

- Message Flow (Поток сообщений) используется для передачи сообщений между двумя участниками. Поток сообщений соединяет два различных пула. Он должен касаться границы пула или объекта потока управления в пуле. Он не может объединять два объекта одного пула. Изображается в виде пунктирной линией, которая начинается с пустого кружка и заканчивается пустой стрелкой;

- Association (Ассоциация) используется для ассоциации информации и артефактов с объектами потока управления. Информация может быть представлена текстом или графическими объектами. Кроме того, ассоциация может указывать на то, используется ли действие для компенсации. Ассоциация отображается одиночной точечной линией;

- Data Association (Ассоциация данных) используются для перемещения объектов данных, свойств и входящей/исходящей информации действий, процессов и глобальных заданий. Результаты ассоциаций данных не оказывают прямого влияния на поток процесса. Ассоциация данных изображается пунктирной тонкой стрелкой. Ассоциация данных всегда имеет источник, цель и возможную информацию о трансформации данных. При выполнении ассоциации данных, данные копируются из источника к цели.

Swim lanes (букв. «Плавательные дорожки», иначе говоря «Разделительные дорожки») позволяют группировать элементы модели по пулам и дорожкам, распределяя между ними обязанности:

- Pool (пул) выступает как контейнер для потока управления между действиями или как определенный участник бизнес-процесса. Процесс полностью содержится в пуле. Поток управления может пересекать дорожки (lanes) пула, но не может пересекать границы пула. Взаимодействие между пулами осуществляется через потоки сообщений. Каждый пул может выступать как «черным», так и «белым» ящиком, детализируя или скрывая свою внутреннюю структуру. В случае «черного ящика» поток сообщений соединяет границы пула, в случае «белого ящика» - его определенные действия. Любое взаимодействие (Collaboration) имеет хотя бы два пула (т. е., участника). Каждый пул отображается прямоугольником, в левой (верхней) части которого пишется имя пула. Обычно прямоугольник проходит через всю диаграмму по вертикали или по горизонтали. Если в диаграмме выделен главный пул - он может не обрамляться границами;

- Lane (дорожка) является составной частью пула. Служит для группировки и организации действий в пуле. Изображает горизонтальным или вертикальным поименованным прямоугольником длинной как и весь процесс. BPMN строго не определяет назначение линий. Они могут использоваться для отображения внутренних ролей (например Менеджер), систем (например, информационная система), или отдел организации и т. д.

Artifacts (Артефакты) используются для предоставления дополнительной информации о процессах. Существуют два стандартных артефакта (Group (Группа), Text Annotation (Аннотация), однако для своих нужд разработчики могут создавать любые другие. Текстовая аннотация служит для дополнительного описания элемента диаграммы. Изображается половинкой прямоугольника. Группа служит для группировки элементов диаграммы. Изображается прямоугольником с закругленными углами в пунктирную через точку линию. Артефакты не могут выступать как элементы потока управления, не могут соединяться потоками управления или сообщения, на них не накладываются ограничения пулов и дорожек. Таким образом, например, группа может пересекать границы пула для объединения элементов диаграммы.

Отдельно следует выделить особый элемент BPMN, который не отображается отдельным графическим элементом, но присутствует или предполагается на любой диаграмме - это участник (participant). Под участником может пониматься некая сущность - бизнес-партнер (например, компания-поставщик) или роль процесса (например, покупатель), участвующая в процессах взаимодействия. Именно участника отображают пулы BPMN.

С понятием участника тесно связаны диаграммы взаимодействия (совместные диаграммы) BPMN. В ранних спецификациях эти диаграммы выделяли в отдельный тип и называли глобальными (Collaboration (global)). На диаграмме взаимодействия показаны несколько пулов и потоки сообщений между ними.

В BPMN 2.0 определены два основных типа процессов процессы хореографии и процессы оркестровки. Процессы оркестровки представляют собой набор действий или взаимодействие внутри компании. С этими процессами наиболее часто работают бизнес-аналитики. В BPMN к ним относят частные (внутренние) и абстрактные (открытые) процессы:

- Частный (public) бизнес-процесс выполняется внутри организации. Этот тип бизнес-процесса часто называют workflow или BPM-процесс. В области СОА этот процесс часто связывают с оркестровкой служб. Частный процесс подразделяется на два вида: исполняемые и неисполняемые. Исполняемый процесс создается и моделируется для выполнения, неисполняемый служит лишь для оценки поведения процесса на определенном уровне детализации бизнес-процессов компании;

- Абстрактный (abstract, это название взято еще из BPMN 1.2) (public) бизнес-процесс необходим для демонстрации взаимодействия между частными бизнес-процессом и другим процессом или участником процесса. Абстрактным процессом можно назвать тот, в котором есть действия по коммуникации с другими участниками процесса. Все остальные внутренние действия частного процесса не показываются на схеме абстрактного. Так, с помощью открытого процесса можно показать последовательность обмена сообщениями между процессами.

BPMN 2.0 стал поддерживать процессы хореографии, основной целью которых стало формализация взаимоотношений между бизнес-партнерами (организациями, компаниями), участниками некоторых совместных операций.

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

Основным элементом диаграмм хореографии стало действие хореографии (Choreography Activity) - некий этап взаимодействия между двумя сторонами. Единое, неделимое действие, задача хореографии описывает процесс обмена сообщениями между двумя участниками. Название процесса и имена участников подписываются на графическом элементе задачи хореографии - скругленном прямоугольнике с тремя областями. Соединяются задачи потоками управления, которые могут проходить через шлюзы. Существуют несколько специфических типов потоков управления и особенностей их использования в диаграммах этого типа. Диаграммы хореографии могут быть как детализированы с помощью диаграмм взаимодействия, так и присутствовать на них.

Процессы хореографии поддерживались в BPMN 1.2 в виде диаграмм взаимодействия, однако специалисты находили в этом подходе ряд существенных недостатков, например, Геро Декер говорит о ненужной избыточности, несоответствии потоков управления и событий запуска процессов. Введение элементов хореографии устранила часть этих проблем, но и породило свои, например, проблемы очередности взаимодействия между множеством участников.

2.5 Стандарт EPC

EPC (Event-Driven Process Chain, событийная цепочка процессов) - нотация отображения хода выполнения процесса, ключевыми элементами которой являются События и Функции. Нотация EPC была разработана в 90х годах XX века. EPC придумал немецкий профессор Вильгельм-Август Шеер в рамках методологии ARIS.

Диаграмма бизнес-процесса в EPC должна начинаться и заканчиваться Событием. За Функцией всегда должно следовать Событие, т. е., выполнение Функции создает некоторое событие (состояние). Документы, организационные звенья, информационные и материальные потоки, элементы информационной системы (программное обеспечение, базы данных) имеют свое графическое обозначение. Для ветвления процесса используются операторы И, ИЛИ, исключающее ИЛИ.

EPC используется на низших уровнях описания бизнес-модели, когда стоит задача описать подробный ход выполнения бизнес-процесса. Функции EPC могут быть декомпозированы (разбиты на детальные бизнес-процессы только в нотации EPC).

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

К преимуществам EPC относится возможность очень детально и точно описать выполнение бизнес-процесса, показать на диаграмме в графическом виде всех исполнителей, все используемые объекты. Также плюсом EPC-диаграмм является тот факт, что, как и на диаграммах IDEF0, на них можно указать входные и выходные данные каждой функции, проследить логику передвижения входных и выходных данных от блока к блоку. К тому же, в отличие от всё той же IDEF0, появилась возможность распараллеливать процесс, направляя его только по одной из альтернативных веток (в IDEF0 если и добавляем параллельность в выполнении, то все параллельные функции будут при этом выполняться одновременно). Достоинством также мне показалась возможность указать исполнителя по каждому этапу (читай: функции). Но, в IDEF0 исполнитель указан на каждом уровне декомпозиции единожды, и от его имени тянутся стрелки ко всем исполняемым им блокам. В EPC, чтобы подсчитать, какое количество действий выполняет исполнитель, нужно пробежаться по всем блокам действия и проверять, указан ли по нему нужный нам исполнитель.

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

В целом нотация EPC является признанной во всем мире как одна из лучших нотаций для построения бизнес-процессов и моделирования работы предприятия.

2.6 Выбор метода моделирования

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

3. Построение модели бизнес-процесса

Бизнесс-процесс функционирования частного предприятия «Пиццерия» будет построен с использованием нотации BPMN, так как именно эта методология позволяют наиболее точно и детально описать процесс обслуживания клиента, а также создать имитационную модель предприятия для оптимизации количества обслуживающего персонала и используемой техники. Организационная структура приведена в приложении «А».

Задача «Функционирование «Пиццерии»» будет представлена на нулевом уровне в нотации BPMN, так как это позволит показать в общем виде всю систему работы данного заведения.

В 1-ом уровне функционирование «Пиццерии» будет рассмотрено более подробно, но все равно достаточно поверхностно, хотя уже можно будет увидеть первые шаги по оптимизации деятельности предприятия.

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

- Предоставление клиенту туалетных услуг;

- Какую пиццу желает клиент;

- Хватает ли денег у клиента для произведения оплаты.

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

Опираясь на статистические данные, было выдвинуто предположение, что в среднем клиент может позволить себе простоять в очереди 15 минут. По истечению этого времени клиенты, чаще всего, уезжают в поисках менее загруженной пиццерии, что также нашло отображение в выполненной диаграмме. Также, полагаясь на статистику и закон нормального распределения, было сформулировано примерное количество клиентов, прибывающее в пиццерию в течении дня. Было выяснено, что в пиковые часы, то есть с 18:00 до 21:00, в данной пиццерии можно наблюдать катастрофические очереди, что ведет к огромным потерям клиентуры.

...