Бизнес процесс в визио пример. Схема бизнес процесса для нетерпеливых

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

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

Непосредственное моделирование лучше всего начать с указания наименования и уточнения границ процесса. Границы можно зафиксировать сразу в виде событий на схеме. В нашем примере граничными событиями будут «Выявлена потребность клиента» и «Потребность подкреплена взаимными обязательствами» (см. рис. 3).

Рис. 3. Заголовок и границы процесса

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

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

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

Упрощенный пример описания процесса показан на рис. 5.

Рис. 5. Упрощенный пример описания процесса

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

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

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

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

Введение

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

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

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

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

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

Проблема данной курсовой работы звучит так: насколько практичны в использовании (простоты, наглядны и информативны) схемы, проектируемые в MS Visio.

В качестве объекта выступает бизнес-моделирование.

Предметом обозначим: моделирование бизнес-процессов предприятия, занимающегося оказанием услуг по автоперевозкам, в MS Visio.

Исходя от проблемы, обозначим целью: определить насколько практичны в использовании схемы, проектируемые в MS Visio, на примере транспортной компании (ТК) ООО «ЭкоТранс».

Для достижения поставленной цели необходимо решить следующие задачи:

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

Ознакомиться с деловой графикой в MS Visio;

Проанализировать бизнес-процессы ТК ООО «ЭкоТранс»

Описать бизнес-процессы ТК ООО «ЭкоТранс» с использованием бизнес-моделирования в Microsoft Visio

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

1. Методологии описания предметной области

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

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

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

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

1.1 Понятие о семействе стандартов IDEF

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

IDEF-методология создавалась в рамках проводимой в США программы компьютеризации промышленности ICAM (Integrated Computer Aided Manufacturing), в ходе реализации которой выявилась потребность в разработке методов анализа процессов взаимодействия в производственных системах. Отсюда и происходит название данного семейства стандартов - Icam DEFinition - IDEF.

В настоящий момент к семейству IDEF можно отнести следующие стандарты:

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

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

IDEF1X (IDEF1 Extended) - методология построения реляционных структур. IDEF1X относится к типу методологий “сущность-взаимосвязь” (ER - Entity-Relationship) и, как правило, используется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе;

IDEF2 - методология динамического моделирования развития систем. В связи с весьма серьезными сложностями анализа динамических систем от этого стандарта практически отказались, и его развитие приостановилось на самом начальном этапе.

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

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

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

Наиболее подробно рассмотрим стандарты, которые потребуются при описании бизнес-процессов в данной курсовой работе, это: IDEF0, IDEF3.

Функциональная методика IDEF0.

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

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

a) Функциональный блок (Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, "производить услуги"). На диаграмме функциональный блок изображается прямоугольником (Рисунок 1.1). Каждая из четырех сторон функционального блока имеет свое определенное значение (роль), при этом:

Верхняя сторона имеет значение "Управление" (Control);

Левая сторона имеет значение "Вход" (Input);

Правая сторона имеет значение "Выход" (Output);

Нижняя сторона имеет значение "Механизм" (Mechanism).

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

Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер.

Рисунок 1.1 - Функциональный блок

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

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

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

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

Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram).

c) Декомпозиция (Decomposition) является основным понятием стандарта IDEF0. Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.

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

Модель IDEF0 всегда начинается с представления системы как единого целого - одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором «А-0» (Рисунок 1.2).

Рисунок 1.2 - Пример контекстной диаграммы

В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания, и зафиксирована точка зрения (Viewpoint).

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

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

В процессе декомпозиции, функциональный блок, который в контекстной диаграмме отображает систему как единое целое, подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы и называется дочерней (Child diagram) по отношению к нему (каждый из функциональных блоков, принадлежащих дочерней диаграмме соответственно называется дочерним блоком - Child Box). В свою очередь, функциональный блок - предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит - родительской диаграммой (Parent Diagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. Важно отметить, что в каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок, или исходящие из него фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0 - модели. Наглядно принцип декомпозиции представлен на рисунке 1.3. Следует обратить внимание на взаимосвязь нумерации функциональных блоков и диаграмм - каждый блок имеет свой уникальный порядковый номер на диаграмме (цифра в правом нижнем углу прямоугольника), а обозначение под правым углом указывает на номер дочерней для этого блока диаграммы. Отсутствие этого обозначения говорит о том, что декомпозиции для данного блока не существует.

Часто бывают случаи, когда отдельные интерфейсные дуги не имеет смысла продолжать рассматривать в дочерних диаграммах ниже какого-то определенного уровня в иерархии, или наоборот - отдельные дуги не имеют практического смысла выше какого-то уровня. Например, интерфейсную дугу, изображающую “деталь” на входе в функциональный блок “Обработать на токарном станке” не имеет смысла отражать на диаграммах более высоких уровней - это будет только перегружать диаграммы и делать их сложными для восприятия. С другой стороны, случается необходимость избавиться от отдельных “концептуальных” интерфейсных дуг и не детализировать их глубже некоторого уровня. Для решения подобных задач в стандарте IDEF0 предусмотрено понятие туннелирования. Обозначение “туннеля” (Arrow Tunnel) в виде двух круглых скобок вокруг начала интерфейсной дуги обозначает, что эта дуга не была унаследована от функционального родительского блока и появилась (из “туннеля”) только на этой диаграмме. В свою очередь, такое же обозначение вокруг конца (стрелки) интерфейсной дуги в непосредственной близи от блока - приёмника означает тот факт, что в дочерней по отношению к этому блоку диаграмме эта дуга отображаться и рассматриваться не будет. Чаще всего бывает, что отдельные объекты и соответствующие им интерфейсные дуги не рассматриваются на некоторых промежуточных уровнях иерархии - в таком случае, они сначала “погружаются в туннель”, а затем, при необходимости «возвращаются из туннеля».

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

Стандарт документирования технологических процессов IDEF3.

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

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

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

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

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

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

Существуют два типа диаграмм в стандарте IDEF3, представляющие описание одного и того же сценария технологического процесса в разных ракурсах. Диаграммы, относящиеся к первому типу называются диаграммами Описания Последовательности Этапов Процесса (Process Flow Description Diagrams, PFDD), а ко второму - диаграммами Состояния Объекта и его Трансформаций в Процессе (Object State Transition Network, OSTN).

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

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

На рисунке 1.4 изображена диаграмма PFDD, являющаяся графическим отображением сценария обработки детали. Прямоугольники на диаграмме PFDD называются функциональными элементами или элементами поведения (Unit of Behavior, UOB) и обозначают событие, стадию процесса или принятие решения. Каждый UOB имеет свое имя, отображаемое в глагольном наклонении и уникальный номер. Стрелки или линии являются отображением перемещения детали между UOB-блоками в ходе процесса.

Рисунок 1.4 - Диаграмма PFDD сценария обработки детали

Объект, обозначенный J1 - называется перекрестком (Junction). Перекрестки используются для отображения логики взаимодействия стрелок (потоков) при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fan-out Junction) стрелок. Перекресток не может использоваться одновременно для слияния и для разветвления. При внесении перекрестка в диаграмму необходимо указать тип перекрестка. Классификация возможных типов перекрестков приведена в таблице 1.

Таблица 1 - Классификация типов перекрестков

Наименование	Смысл в случае слияния стрелок (Fan-in Junction)	Смысл в случае разветвления стрелок (Fan-out Junction)
Asynchronous AND	Все предшествующие процессы должны быть завершены	Все следующие процессы должны быть запущены
	Все предшествующие процессы завершены одновременно	Все следующие процессы запускаются одновременно
	Один или несколько предшествующих процессов должны быть завершены	Один или несколько следующих процессов должны быть запущены
	Один или несколько предшествующих процессов завершаются одновременно	Один или несколько следующих процессов запускаются одновременно
XOR (Exclusive OR)	Только один предшествующий процесс завершен	Только один следующий процесс запускается

Сценарий, отображаемый на диаграмме, можно описать в следующем виде:

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

Каждый функциональный блок UOB может иметь последовательность декомпозиций, и, следовательно, может быть детализирован с любой необходимой точностью. Под декомпозицией мы понимаем представление каждого UOB с помощью отдельной IDEF3 диаграммы. Например, мы можем декомпозировать UOB «Окрасить Деталь», представив его отдельным процессом и построив для него свою PFDD диаграмму. При этом эта диаграмма будет называться дочерней, по отношению к изображенной на рисунке 1.4, а та, соответственно родительской. Номера UOB дочерних диаграмм имеют сквозную нумерацию, т.е., если родительский UOB имеет номер «1», то блоки UOB на его декомпозиции будут соответственно иметь номера «1.1», «1.2» и т.д. Применение принципа декомпозиции в IDEF3 позволяет структурировано описывать процессы с любым требуемым уровнем детализации.

Если диаграммы PFDD технологический процесс «С точки зрения наблюдателя», то другой класс диаграмм IDEF3 - OSTN позволяет рассматривать тот же самый процесс «С точки зрения объекта». На рисунке 1.5 представлено отображение процесса окраски с точки зрения OSTN диаграммы. «Состояния объекта» (в нашем случае детали) и «Изменение состояния» являются ключевыми понятиями OSTN диаграммы. Состояния объекта отображаются окружностями, а их изменения направленными линиями. Каждая линия имеет ссылку на соответствующий функциональный блок UOB, в результате которого произошло отображаемое ей изменение состояния объекта.

Рисунок 1.5 - Процесс окраски с точки зрения OSTN диаграммы

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

Для описания бизнес-процессов существует множество инструментальных средств BPWin, ERWin, PowerDesigner, Business Studio, ELMA BPM, Visual Paradigm и другие.

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

2.1 Технические особенности. Хранение данных

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

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

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

Рисунок 2.1 - Набор готовых шаблонов MS Visio

2.2 Поддерживаемые методологии и нотации

Поскольку набор символов и шаблонов Visio может быть произвольно расширен и сам продукт не предполагает глобальных ограничений на возможности применения символов и связей между ними, описание бизнес-процессов с помощью Visio формально может быть осуществлено в рамках практически любой методологии. При этом в комплекте поставки продукта в любой редакции (Standard, Professional) есть набор шаблонов моделей для наиболее распространенных нотаций, таких как диаграммы потоков данных, диаграммы цепочки добавленного качества, диаграммы типа Event-driven Process Chain, IDEF0, SwimLane, а также шаблоны для моделирования оргструктур компаний.

3. Анализ предметной области ООО «ЭкоТранс»

Транспортная компания ООО «ЭкоТранс» основана 2008 году. Первые услуги по автоперевозке грузов были оказаны потребителям, ведущим бизнес в Орловской области. Многие крупнейшие предприятия региона заключили с компанией долгосрочные контракты на грузопассажирские перевозки. Для ООО «ЭкоТранс» услуги грузоперевозки (Орловская область) внутри региона стали успешным стартом для дальнейшего развития. Сегодня география транспортных услуг шагнула далеко за пределы родной области. Расширение географии своей деятельности потребовало увеличения количества современного грузового автотранспорта, поэтому для доставки грузов теперь используется не только свой собственный обширный автопарк, но и автомобили партнёров.

ООО «ЭкоТранс» не только обеспечивает грузоперевозки по России, но и предоставляет клиентам сопутствующие услуги, такие как: экспедирование и страховка груза.

a) Транспортное экспедирование. Данная услуга позволяет клиенту не только облегчить процесс грузоперевозки, но и удешевить его. Транспортное экспедирование грузов состоит из нескольких видов услуг:

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

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

Планирование маршрута. Выбирается самая скоростная и безопасная схема движения;

Решение прочих проблем, возникающих на пути следования.

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

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

3.1 Организационная структура ООО «ЭкоТранс»

В ООО «ЭкоТранс» Генеральному директору подчиняются: главный бухгалтер, главный инженер, инженер-электрик, системный администратор. Главному бухгалтеру подчиняется бухгалтер. Бухгалтеру подчиняется кладовщик. Главному инженеру подчиняются: кладовщик, механик, медицинский работник, диспетчер. Диспетчеру подчиняются: механик, водители автомобиля, водители автобуса, водители погрузчика. Механику подчиняются: водители автомобиля, водители автобуса, водители погрузчика.

3.2 Бизнес-процесс «Перевозка груза»

Бизнес-процесс «Перевозка груза» включает в себя:

1 Получение заявки. Заказчик отправляет заявку диспетчеру, а диспетчер её принимает.

2 Заключение договора. Между заказчиком и директором заключается договор на основании, которого осуществляется перевозка.

3 Проверка на наличие договора. Диспетчер проверят наличие договора.

4 Обработка заявки. В соответствии с техническими характеристиками транспортного средства диспетчер на основании заявки, учитывая габариты, массу груза и условия перевозки распределяет транспортные средства.

5 Выдача путевого листа. Диспетчер вызывает водителя, сообщает ему о предстоящем рейсе и маршруте движения и выдает путевой лист.

6 Прохождение медицинского осмотра. Водитель проходит медицинский осмотр.

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

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

9 Отметка об исправности ТС в путевом листе. Водитель ставит отметку об осмотре ТС в путевом листе.

10 Осмотр ТС. Водитель предоставляет транспортное средство для осмотра механику. Механик осматривает транспортное средство. Проверяет: герметичность и действие тормозных систем, систем питания, охлаждения, системы выпуска отработанных газов; исправность рулевого управления, внешних световых приборов, стеклоочистителей; крепление колес; наличие медицинской аптечки, огнетушителя, знака аварийной остановки.

11 Отметка об исправности ТС в путевом листе. Механик ставит отметку об исправности ТС в путевом листе.

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

13 Получение документов. Водитель забирает транспортные накладные у заказчика.

14 Возвращение с линии. Водитель с линии возвращается в гараж.

15 Осмотр ТС. При возвращении с линии водитель предоставляет транспортное средство для осмотра механику.

16 Отметка о состоянии ТС в путевом листе. Механик ставит отметку о состоянии ТС в путевом листе.

17 Передача документов в бухгалтерию. Водитель передает транспортные накладные в бухгалтерию.

18 Выписка документов бухгалтерией. Бухгалтерия выписывает документы: акт выполненных работ, счет фактура, счет на оплату.

19 Оплата услуги заказчиком. Бухгалтерия передает выписанные документы для оплаты заказчику. Заказчик оплачивает оказанную услугу.

3.3 ИТ-инфраструктура

информационный сетевой моделирование

Сетевая архитектура (network architecture) - это комбинация топологий, методов доступа к среде передачи данных и протоколов, необходимых для создания работоспособной сети.

ЛВС - локальная вычислительная сеть (LAN, local area network).

В организации ООО «ЭкоТранс» ЛВС выполнена по топологии «звезда».

В ИС объекта обследования используется служба каталогов корпорации Microsoft - Active Directory. Данная служба используется для регулирования групповых политик домена. Домены имеют иерархическую структуру.

В аппаратной части ИС объекта: 2 серверов; 16 рабочих станций.

Программное обеспечение ООО "ЭкоТранс": операционная система Windows XP Servise Pack 2/3, MS Office 2007, антивирусное программное обеспечение - Panda Antivirus Platinum, Налогоплательщик ЮЛ, 1С: Бухгалтерия, 1 С: Зарплата и кадры, ПП "Справочник сертификатов",СКЗИ Крипто Про CSP, ПП "СТЭК-Траст". АРМ "ТРАСТ-Клиент", Система "СТЭК-Траст". АРМ Страхователя, Утилита для ФСС, Документы ПУ 5, CheckXML, Canon Solution Menu, ABBYY FineReader Professional Edition, Total Commander, WinDjView, Adobe Acrobat Professional, WinRAR и другие.

4. Описание бизнес-процессов ТК ООО «ЭкоТранс» с использованием бизнес-моделирования в Microsoft Visio

4.1 Построение модели в нотации IDEF0 и ее декомпозиция

Создадим модель ТК ООО «ЭкоТранс» по методологии IDEF0. Сначала построим контекстную диаграмму бизнес-процесса «Перевозка груза» (Рисунок 4.1). Согласно нотации IDEF0 назовём этот функциональный блок «Перевезти груз».

Рисунок 4.1 - Контекстная диаграмма процесса «Перевозка груза»

Затем разобьём бизнес-процесс «Перевозка груза» на составляющие: «Обработка заявки», «Заключение договора», «Подготовка к перевозке груза», «Оформление документов, необходимых для перевозки груза», «Осуществление перевозки груза». И соответствующим образом декомпозируем функциональный блок «Перевезти груз» (Рисунок 4.2).

Рисунок 4.2 - Диаграмма декомпозиции процесса «Перевозка груза»

Подробнее рассмотрим бизнес-процессы: «Обработка заявки» (Рисунок 4.3); «Подготовка к перевозке груза» (Рисунок 4.4); «Оформление документов, необходимых для перевозки груза» (Рисунок 4.5); «Осуществление перевозки груза» (Рисунок 4.6).

Рисунок 4.3 - Диаграмма декомпозиции процесса «Обработка заявки»

Рисунок 4.4 - Диаграмма декомпозиции процесса «Подготовка к перевозке груза»

Рисунок 4.5 - Диаграмма декомпозиции процесса «Оформление документов, необходимых для перевозки груза»

Рисунок 4.6 - Диаграмма декомпозиции процесса «Осуществление перевозки груза»

4.2 тПостроение модели в нотации IDEF3

Теперь построим модель ТК ООО «ЭкоТранс» используя методологию IDEF3. Декомпозиция процесса «Перевозка груза» представлена на рисунке 4.7

Рисунок 4.7 - Диаграмма PFDD декомпозиции процесса «Перевозка груза»

Символ «», означает «Исключающее ИЛИ», он же «XOR» (Exclusive OR).

Заключение

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

Описание бизнес-процессов возможно различными способами: текстовый, табличный, графический. Для их описания существует множество методологий (IDEF0, IDEF3, DFD, WORKFLOW, UML, ARIS и другие) и инструментальных средств (BPWin, ERWin, PowerDesigner и другие).

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

Добавление к простому текстовому описанию бизнес-процессов ООО «ЭкоТранс», графического описания, придало им наглядность. И как следствие, предоставило больше возможностей для системного анализа и оптимизации деятельности компании.

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

Литература

1 Голичев В.Д., Голичева Н.Д., Гусарова О.М. и др. Актуальные вопросы экономики и управления в условиях модернизации. Коллективная монография. - Смоленск: Смолгортипография, 2014. - 212с.

2 Гусарова О.М. Моделирование результатов бизнеса в менеджменте организации // Перспективы развития науки и образования. - Тамбов: Бизнес-Наука-Общество, 2014. - с. 42-43.

Размещено на Allbest.ru

...

Подобные документы

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

практическая работа , добавлен 14.02.2012


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

реферат , добавлен 14.12.2011


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

курсовая работа , добавлен 19.06.2015


Назначение Microsoft Visio. Наборы изображений объектов определенных типов. Требования к программному обеспечению. Характеристики пользовательского интерфейса. Функции, операции и приемы работы Microsoft Visio. Взаимодействие конструктора с приложениями.

контрольная работа , добавлен 19.12.2010


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

реферат , добавлен 29.04.2009


Основні визначення та опис UML. Опис основних компонентів, використаних у Microsoft Visio. Створення діаграми класів в Microsoft Visio 2010. Використання побудованої моделі при модифікаціях системи. Структура системи, її класи, їх атрибути та оператори.

практическая работа , добавлен 07.05.2014


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

дипломная работа , добавлен 21.05.2015


Управление дистанционной настройкой и установкой ПО. История развития VMware ThinApp. Создание пакета автоматической установки Microsoft Office Visio Professional 2007. Анализ программного обеспечения для него. Тестирование полученного msi-пакета.

курсовая работа , добавлен 14.03.2013


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

дипломная работа , добавлен 20.07.2014


Среда Microsoft Visio: понятие, основные функции. Функция автосоединения в Office Visio 2007. Логарифмическая функция правдоподобия. График вероятностей отказа версий программного обеспечения. Визуальное моделирование в UML. Общий вид диаграммы классов.

Для построения схем бизнес процессов часто используют программный пакет Visio. По своей сути он не является CASE средством . Несмотря на это, для простейшего моделирования Visio достаточно удобен. Он позволяет создавать наглядные схемы процессов.

Изначально этот программный продукт разработан и выпускался компанией Visio Corporation. В дальнейшем, он был приобретен Microsoft и вошел в пакет офисных приложений Microsoft Visio. На сегодняшний день последней версией этого программного продукта является Microsoft Visio 2013.

Для построения схем в Visio применяется векторная графика, которая позволяет масштабировать изображение без потери качества. Также, Microsoft Visio обладает широкими возможностями по графическому оформлению диаграмм и схем процессов. Эти свойства делают Visio хорошим инструментом для «рисования» бизнес процессов. Рассматривать его как полноценный инструмент для моделирования, конечно, нельзя.

Новая версия Visio позволяет создавать схемы процессов на основе стандарта моделирования BPMN 2.0 (Business Process Model and Notation) и визуально проверять корректность построения этих диаграмм. Также, в новой версии Visio есть возможность создавать схемы на основе стандарта моделирования UML 2.4

Microsoft Visio 2013 выпускается в двух вариантах – Microsoft Visio Standard и Microsoft Visio Professional. Отличие этих вариантов в основном заключается в составе диаграмм. Версия Professional предоставляет больше видов диаграмм и возможностей по их представлению.

Возможности Visio

Основными преимуществами Visio, по сравнению с CASE средствами, являются:

• легкость создания схем . Для разработки схем процессов не требуется специальное обучение. Рисование диаграмм и схем процессов осуществляется с помощью простого и понятного интерфейса;
• наличие образцов диаграмм . В Microsoft Visio включено большое количество различных образцов диаграмм, что упрощает и ускоряет процесс создания схем бизнес процессов;
• связь схем процессов с данными из офисных приложений . Т.к. Visio входит в состав пакета Microsoft Office, то схемы процесса можно связать с документами и данными из Word, Excel, PowerPoint, Access and Project;
• применение стандартных нотаций . Для создания схем процессов, применяемых в различных

Лабораторная работа №1

Организационное проектирование

Теоретическое обоснование

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

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

Рисунок 1.1 – Модель «процесс»

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

Методические указания к выполнению работы:

Запускаем программу при помощи кнопки «Пуск» или через ярлык на рабочем столе.

Рисунок 1.2 – Главное окно программы MS Visio 2010

Рисунок 1.3 – Главное окно программы MS Visio 2003

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

Из предложенных вариантов описания процессов в меню – выбираем опцию EPC Diagramm.

Новый файл можно создать также в рабочем режиме при открытых других файлах, через основное меню. Выбираем Файл – новый (New) – Бизнес-процесс (Business Process) – и нужный нам тип – ePC Diagram.
В меню слева расположены объекты, которые мы будем использовать при построении схемы процесса.

‒ Событие

‒ Функция

‒ Исполнитель

И логические операторы: и, исключающее или, неисключающее или.

Рисунок 1.4 – Объекты для построения схемы процесса

Использование программного средства Microsoft Visio удобно, просто и доступно в применении для построения графических схем бизнес-процессов.

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

Упражнение 1. Правила построения схем процессов в нотации epC

Мы находимся в программном пакете Visio и рассматриваем представление бизнес-процессов под названием Event – driven Process Chain – или EPC. Схемы данного типа удобны, просты в прочтении и активно используются в настоящее время на практике. Разберем подробно, как правильно построить схему процесса. Будем пользоваться объектами, которые расположены в меню слева.

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

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

Попробуем выстроить некую цепочку действий. Чтобы каждый раз не настраивать свойства объекта, воспользуемся функцией копирования. Для этого правой клавишей мыши выделяем объект, нажимаем «копировать», а затем «вставить». Лишние объекты можно удалять кнопкой на панели инструментов либо клавишей Delete на клавиатуре.

На практике каждая работа выполняется каким-то человеком, исполнителем. Для обозначения исполнителя выбираем объект. Например, желтый овал. И располагаем его обязательно справа от Функции, не забывая указывать организационную единицу. Это может быть отдел, группа, департамент, либо же просто должность исполнителя. Соединяем наш объект с другими посредством линии связи. В этом случае линия должна быть прямой – без начальных и конечных стрелок.

Варианты

1. Бронирование билетов.

2. Покупка через Интернет-магазин.

3. Покупка квартиры.

4. Банковское кредитование.

5. Подключение кабельного телевидения.

6. Сдача в аренду торговых площадей.

7. Прием к врачу.

8. Техническое обслуживание.

9. Гостиница.

10. Страховая компания.

11. Библиотека.

12. Курсы по повышению квалификации.

13. Грузовые перевозки.

14. Прокат автомобилей.

15. Инвестирование свободных средств.

2. Используя вариант предприятия, представленного в первом задании, разработайте на новой странице организационную диаграмму:

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

‒ настройте внешний вид организационной диаграммы.

Приложение 1

Проверка правильности построения диаграммы

ТП1 Юридическое оформление договора

Правило 1: Диаграмма функции EPC должна начинаться как минимум одним стартовым событием (стартовое событие может следовать за интерфейсом процесса) и завершаться как минимум одним конечным событием (конечное событие может предшествовать интерфейсу процесса).

Ошибок не обнаружено.

Правило 2: По ходу выполнения процесса события и функции должны чередоваться (событие и функция могут быть связаны через операторы).

Ошибок не обнаружено.

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

Ошибок не обнаружено.

Правило 4: На диаграмме не должны присутствовать неименованные связи.

Ошибок не обнаружено.

Правило 5: За единичным событием не должны следовать операторы «OR» или «XOR».

Ошибок не обнаружено.

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

Ошибок не обнаружено.

Правило 7: Операторы могут объединять или разветвлять только элементы одного типа. Объединение или ветвление одновременно функций и событий невозможно.

Ошибок не обнаружено.

Правило 8: Для каждой функции должна быть установлена связь типа «выполняет» минимум с одним и максимум с тремя субъектами.

Ошибок не обнаружено.

Правило 9: На диаграмме одно и то же событие должно присутствовать только один раз.

Ошибок не обнаружено.

Лабораторная работа №1

Задача описания бизнес-процессов при помощи MS Visio.

Дмитрий Пинаев / Современные технологии управления

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

Описание системы управления

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

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

• описание и оптимизация бизнес-процессов;
• проектирование системы управления для нового бизнес-направления;
• внедрение автоматизированных систем управления;
• построение системы менеджмента качества.

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

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

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

Организационная структура

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

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

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

Для моделирования бизнес-процессов Visio 2003 предлагает бизнес-аналитику шаблоны для создания 7 видов диаграмм:

1. Basic Flowchart;
2. Cross-Functional Flowchart (с вертикальным или горизонтальным расположением дорожек);
3. EPC (Event-driven Process Chain);
4. IDEF0;
5. DFD (Data Flow Diagrams) в двух нотациях: Гейна-Сарсона и Йордана-Де Марко;
6. WFD (Work Flow Diagram)

Из перечисленных нотаций наиболее популярными являются IDEF0 и EPC.

Нотация моделирования IDEF0 базируется на методологии структурного анализа и проектирования SADT (Structured Analysis and Design Technique).

Диаграмма процесса «Закупка ТМЦ», изображенная с помощью нотации IDEF0

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

Типы стрелок нотации IDEF0

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

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

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

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

Диаграмма процесса "Обработка заказа", изображенная с помощью нотации EPC

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

Основные графические элементы диаграммы EPC:

• функции,
• события,
• организационные единицы, ответственные за исполнение функций,
• информационные или материальные объекты, которые используются при выполнении функций,
• коннекторы (AND, OR, XOR).

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

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

Организационная структура

В шаблоне Organization Chart содержится набор графических элементов, обозначающих виды должностей:

• executive - руководитель высшего звена,
• manager - руководитель,
• position - должность,
• consultant - консультант,
• vacancy - свободная вакансия,
• assistant - помощник.

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

Владельцы процессов

После описания организационной структуры необходимо определить владельца процесса из числа руководителей и менеджеров компании. Владелец - это лицо, отвечающее за результат процесса и обладающее полномочиями для распоряжения ресурсами (материальными, трудовыми и пр.), необходимыми для его выполнения. Для того, чтобы назначить воадельца процесса на диаграммах IDEF0 необходимо завести пользовательский параметр «Process owner» у всех процессов и внести в него название должности из организационной структуры.

Заполнение свойств процесса

По разработанным моделям бизнес-процессов Microsoft Visio 2003 позволяет сформировать отчеты в формате:

• страницы Microsoft Excel,
• веб-страницы (HTML-файл),
• visio shape для внедрения отчета как таблицу Excel непосредственно в диаграмму Visio,
• файл XML.

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

Сформированный отчет по процессам в формате Microsoft Excel

Отличительной чертой Visio 2003 является простота и удобство создания диаграмм и интеграция с другими продуктами Microsoft Office. Благодаря этому, специалисты, увидевшие Visio в первый раз, уже через несколько часов начинают создавать диаграммы бизнес-процессов и организационных структур и использовать эти диаграммы в документах Microsoft Word.