Главная › Взыскание ущерба › Microsoft Visio для образовательных учреждений. «Схема рабочего процесса. Тренинг "Описание бизнес-процессов в Microsoft Visio"

Microsoft Visio для образовательных учреждений. «Схема рабочего процесса. Тренинг "Описание бизнес-процессов в Microsoft Visio"

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

Зачем автоматизировать описание бизнес-процессов

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

Можно выделить пять основных групп задач:

-разработка внутрифирменных положений и должностных инструкций. Формализованные описания бизнес-процессов дают ответ на вопрос, как «движется» тот или иной документ в компании, какие функции выполняют конкретные сотрудники и подразделения. На основе этих данных могут быть сформированы положения по структурным подразделениям, должностные инструкции, положения по управлению и документообороту или регламенты бизнес-процессов. При этом некоторые системы (например, ARIS, ЕМ Tool Kit) позволяют формировать подобные документы автоматически, после того как построены модели бизнес-процессов;

- попроцессное калькулирование и планирование. Для точного расчета стоимости тех или иных видов деятельности в компании, а также правильного определения себестоимости выпускаемой продукции используется методология попроцессного калькулирования (Activity based costing) 1 , в основе которой должно лежать формализованное описание бизнес-процессов. По мнению авторов статьи, технологию Activity based costing можно реализовать и в Excel, однако если в бизнес-процессах компании произойдут какие-либо изменения (например, в последовательности действий сотрудников, штатном расписании или заработной плате), построенную модель придется полностью переделывать. В то время как специализированная система позволит с минимальными затратами труда учесть подобные перемены при расчете стоимости бизнес-процессов и себестоимости продуктов или услуг методом Activity based costing. Аналогичная ситуация складывается с использованием бюджетирования на основе действий (Activity based budgeting) 2 . Серьезным аргументом в пользу необходимости описания бизнес-процессов является то, что оно позволяет проследить, где и как создается поток ценности для клиентов компании, и устранить источники неоправданных затрат;

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

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

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

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

Личный опыт
Алексей Прошин, директор по инструментальным средствам описания бизнес-процессов компании «ФОРС - Центр разработки» (Москва) Одна из задач, которую удается решить, описав бизнес-процессы, -успешное внедрение информационной системы. Главная причина неудачной реализации IT-проектов заключается в несовпадении представлений об IT-технологиях у людей, занимающихся бизнесом, и тех, кто реализует их на практике. Чтобы этого избежать, все должны говорить на одном языке, понятном и менеджерам высшего звена, включая финансовых директоров. Такой язык можно создать при помощи инструментальных средств моделирования и анализа бизнес-процессов. На их основе строятся диаграммы, графические модели, шаг за шагом демонстрирующие, как построены в компании бизнес-процессы, как организовано взаимодействие между людьми и что необходимо изменить. Особо хочется подчеркнуть, что главная цель описания бизнес-процессов - понимание и оптимизация взаимодействия между всеми составляющими компании, вовлеченными в решение задач бизнеса. Необходимость же автоматизации тех или иных операций - это вопрос, ответ на который может быть получен, только когда есть четкое представление об их месте и назначении в общей картине бизнеса.

Критерии выбора

Выбор системы будет зависеть от задач, стоящих перед компанией, а также ее финансовых возможностей. Стоимость программных средств на пять рабочих мест может составлять от 3 тыс. до 30 тыс. долл. США в зависимости от функциональных возможностей. Однако, по мнению авторов, при выборе программного обеспечения помимо стоимости основными критериями являются: методология описания бизнес-процессов, возможность использования атрибутов и автоматического обновления моделей, интеграция с учетными или ERP-системами.

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

Сегодня существует два основных подхода к графическому представлению бизнес-процессов: методология SADT/IDEF0 (Structured Analysis and Design Technique/ ICAM DEFinition) и ARIS (Architecture of Integrated Information Systems). С точки зрения пользователя, бизнес-процессы в стандарте IDEF0 проще и понятнее (см. рис. 1). Схемы бизнес-процессов, составленные по методологии ARIS, будут содержать больше данных, однако они достаточно сложны для восприятия пользователями, которые не имеют специальных навыков работы с ними. Поэтому, если предприятие приобретает программное средство описания бизнес-процессов для разработки регламентов, положений, должностных инструкций и анализа бизнес-процессов, можно рекомендовать использовать системы, поддерживающие стандарты IDEFO. Для оценки стоимости бизнес-процессов, разработки технического задания на внедрение ERP-систем, создания системы внутреннего контроля и управления рисками, а также разработки сбалансированной системы показателей больше подойдет методология ARIS. На рис. 2 приведен фрагмент ARIS-модели бизнес-процесса «Предоставление кредита» в графическом представлении (нотации) еЕРС (extended Event-driven Process Chain).

Использование атрибутов

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

Автоматическое обновление моделей бизнес-процессов

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

Интеграция с другими системами

Интеграция программ по описанию бизнес-процессов с учетно-финансовыми и ERP-системами позволяет автоматически переносить в модели бизнес-процессов различные характеристики объектов. Например, стоимость используемых материалов, количество поступивших от клиентов заказов, время выполнения отдельных действий и другие данные, которые учитываются в таких системах, могут быть добавлены как атрибуты объектов. Интеграция обеспечивается за счет разработки интерфейсов или использования таблиц MS Excel. Это значительно снижает долю ручного труда по сбору и вводу информации. Как правило, такие решения подходят для крупных и средних компаний, которые планируют внедрить методику попроцессного калькулирования или сбалансированную систему показателей.

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

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

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

MS Visio (Microsoft);

ЕМ Tool Kit (ИК «Ориентсофт»);

ARIS (IDS Scheer AG);

Интегрированные системы (BAAN/Dem, Oracle Designer).

MS Visio

Визуальное средство MS Visio - это приложение из семейства Microsoft Office 2000. Оно не является специализированным программным обеспечением для описания бизнес-процессов, поэтому его функциональные возможности весьма ограниченны и не позволяют проводить глубокий анализ и оценку моделей, разрабатывать какие-либо регламентирующие документы, а также автоматически вносить изменения в модели. MS Visio представляет собой нетрадиционный и очень гибкий графический редактор, который обеспечивает быстрое наглядное представление небольших по объему и обобщенных по содержанию моделей. Стоимость одной лицензии варьируется от 225 долл. США за стандартную конфигурацию до 550 долл. США за профессиональную.

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

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

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

ЕМ Tool Kit

ЕМ Tool Kit (Enterprise Modeling Tool Kit) 4 позволяет описывать бизнес-процессы в формате IDEF0, формировать нормативные документы, регламентирующие деятельность компании (регламенты документооборота, должностные инструкции и др.), а также проводить аудит организационных систем, например системы менеджмента качества, внутреннего контроля и т.д. Средняя стоимость системы на пять рабочих мест составляет около 3 тыс. долл. США.

Преимущества. Система позволяет создавать вложенные модели бизнес-процессов (см. рис. 3 на с. 92), автоматически формировать отчеты и определять атрибуты для действий, выполняемых в ходе бизнес-процесса. Нужно отметить, что на российском рынке программных систем представлены модули, позволяющие автоматически загружать необходимые атрибуты из программных продуктов, разработанных фирмой «1С». Благодаря использованию атрибутов ЕМ Tool Kit дает возможность оценить стоимость и продолжительность того или иного бизнес-процесса. Возможна организация одновременной работы нескольких пользователей.

Недостатки. Среди наиболее существенных недостатков системы можно отметить отсутствие операторов «и», «или», что затрудняет описание логики бизнес-процессов. Стандартные инструменты ЕМ Tool Kit не позволяют реализовать расширенную методологию попроцессного калькулирования и расчет полной себестоимости выпускаемой продукции, предоставляемых услуг или других объектов затрат.

Рекомендации. ЕМ Tool Kit ориентирован на небольшие и средние компании, может быть использован для разработки внутрифирменных стандартов и положений, технических заданий на внедрение информационных систем, для анализа и оптимизации бизнес-процессов, а также для внедрения системы менеджмента качества.

Аналогом ЕМ Tool Kit является система BPwin, которая обладает большими возможностями в части поддерживаемых методологий (IDEFO, IDEF1X, IDEF3) и формирования отчетов. Однако, по мнению авторов, BPwin больше подойдет специалистам 1Т-службы, так как в первую очередь ориентирована на решение задач, связанных с внедрением корпоративных информационных систем. /

Личный опыт
Олег Костиков, директор по экономике ОАО «Балтийский завод» (Санкт-Петербург) Состояние дел на ОАО «Балтийский завод» на момент начала внедрения корпоративной информационной системы (КИС) требовало глубокого анализа структуры предприятия, функций различных подразделений, документооборота для понимания ситуации «как есть» и выявления проблем и путей их решения

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

ARIS

Платформа ARIS компании IDS Scheer AG является специализированным набором инструментов для структурированного описания и анализа бизнес-процессов. В состав системы входят функциональные модули для:

Проектирования и оптимизации бизнес-процессов (ARIS Easy Design, ARIS Toolset, ARIS Business Design, ARIS Business Architect, ARIS Business Server);

Динамического анализа и оптимизации бизнес-процессов (ARIS Simulation);

Разработки и внедрения системы менеджмента качества (ARIS Quality Management Scout);

Мониторинга и контроля эффективности бизнес-процессов (ARIS Process Perfomance Manager);

Управления процедурами, обеспечивающими работу системы внутреннего контроля за формированием финансовой отчетности (ARIS Audit manager);

Разработки, внедрения и поддержания системы управления операционными рисками (ARIS Process Risk Scout);

Создания системы попроцессного калькулирования - Activity based costing (ARIS Process Cost Analyzer);

Проектирования системы сбалансированных показателей (ARIS BSC) и др.

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

Организационной структуры (Organizational Chart);

Цепочки добавленной стоимости (Value Added Chain Diagram);

Расширенной событийно-ориентированной цепочки процесса (extended Event Driven Process Chain).

Преимущества. ARIS-платформа обладает большим набором функций. В ней предусмотрена возможность анализа построенных моделей бизнес-процессов, определения «узких» мест и оптимизации бизнес-процессов на основе анализа «что-если». Иными словами, пользователь может изменять те или иные бизнес-процессы, к примеру перераспределить полномочия сотрудников и оценить, насколько увеличится время на выполнение тех или иных операций или стоимость работ. Модуль ARIS Process Cost Analyzer позволяет реализовать традиционную методологию Activity based costing для определения стоимости бизнес-процессов, а результаты использовать в модуле стратегического управления предприятием (ARIS BSC). Применяя дополнительные модули и внутренний язык программирования, пользователь может сформировать любые регламенты и положения, а также управлять рисками компании, создать систему менеджмента качества и внутреннего контроля.

Недостатки. К недостаткам можно отнести достаточно высокую стоимость программного обеспечения. Графическое представление моделей бизнес-процессов достаточно сложное для восприятия неподготовленных пользователей. Надо также отметить, что для использования, к примеру, ЕМ Tool Kit требуется пройти учебный курс длительностью два-три дня, а для освоения основных функциональных возможностей ARIS придется посетить несколько специализированных учебных курсов продолжительностью от пяти до пятнадцати дней. Кроме того, система содержит большое количество функций, которые, возможно, никогда не будут востребованы. На практике используется не более 15% всех типов моделей, которые могут быть сформированы.

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

Рекомендации. Система подойдет крупным компаниям и холдингам, планирующим внедрять дорогостоящие ERP-системы, проводить сертификацию в соответствии со стандартами ISO 9001:2000, внедрять сбалансированную систему показателей и методику попроцессного калькулирования для бизнес-процессов.

Интегрированные системы

Сегодня многие ERP-системы включают модули, позволяющие составить описание бизнес-процессов. В качестве примера можно привести Oracle Designer и BAAN DEM.

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

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

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

От простого к сложному

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

Личный опыт
Павел Бурков, директор департамента экономического консалтинга МВС Group (Москва) Мы, как и многие, при реинжиниринге бизнес-процессов и их последующей автоматизации пользовались для описания MS Visio. Однако при описании деятельности даже небольших компаний возникали проблемы, хорошо знакомые тем, кто использовал при моделировании программные продукты (например, необходимость многократного занесения одной и той же информации в разные модели и сложности при оперативной корректировке моделей бизнес-процессов). Но самым главным недостатком было отсутствие возможности формирования для клиентов удобных отчетов (регламентов). Именно тогда мы и решили осваивать специализированный программный продукт для описания бизнес-процессов. Сначала это был BPwin. Однако, как нам кажется, представление бизнес-процессов в этой системе не очень удобно для понимания сотрудниками компаний, то есть людей, для которых они и создаются Поэтому для описания бизнес-процессов мы решили использовать Business Studio. Это универсальное средство для моделирования. Предназначено для различных по масштабам и деятельности проектов, поддержки регулярной работы по улучшению и регламентации бизнес-процессов.

Владимир Репин

Генеральный директор ООО «Владимир Репин Менеджмент»

Член ABPMP Russia

Консультант по управлению

Бизнес-тренер

Кандидат технических наук

В статье рассмотрены вопросы выбора нотации для описания процессов с целью последующей регламентации. Сравниваются между собой часто используемые нотации Work Flow, такие как: «Простая блок-схема » в MS Visio, «Процедура» Business Studio, нотация ARIS eEPC и другие. При сравнении нотаций основное внимание уделяется вопросам создания простых и понятных сотрудникам организации схем процессов.

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

Введение

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

Сравнение нотаций

Для сравнения были выбраны следующие нотации описания процессов:

«Простая блок-схема » (с отображением движения документов, с использованием блока «Решение»);
«Простая блока-схема » (без отображения движения документов, без использования блоков «Решение»);
«Процедура» системы Business Studio (один из возможных вариантов представления);
ARIS eEPC.

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

Рис. 1. Схема процесса в нотации «Простая блок-схема » в MS Visio (с движением документов, с использованием блока «Решение»)

На схеме, представленной на Рис. 1, последовательность выполнения операций процесса во времени показана при помощи жирных стрелок, а движение документов — при помощи тонких пунктирных стрелок. Блоки «Решение» использованы классическим образом. Они отображают информацию (вопросы), от которых «зависит» последующий ход процесса. Такой подход к использованию «ромбиков» является весьма распространенным. Но фактически, вся логика принятия решений и формирования тех или иных выходов (документов) должна заключаться внутри операций процесса. Если задуматься, то ценность (смысл) рисования этих «ромбиков» не является очевидным. Что это за объекты: операции процесса, события? Вроде бы, ни то, и ни другое. Это скорее операторы принятия решения по какому-либо условию. Но ведь мы разрабатываем схему процесса для людей, а не пишем компьютерную программу на специальном языке. В компьютерной программе «ромбик» был бы полноценной операцией сравнения условий и т. п. Но на схеме процесса нужно показывать реальные объекты — процессы, выполняемые людьми, документы, информационные системы и т. п. Задумайтесь, корректно ли показывать «ромбики» отдельно от операции процесса на схеме? Вместо этого можно:

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

Сформулируем «плюсы» и «минусы» рассмотренного выше (Рис. 1) способа использования «ромбиков».

«Простая блок-схема » в MS Visio (с движением документов, с использованием блока «Решение»)

На Рис. 2 показан пример того же самого процесса, только описанного без использования блоков «Решение» и документов. Легко проверить, что на этой схеме на 24 графических элемента меньше, чем на схеме Рис. 1. Схема Рис. 2 выглядит гораздо проще. От графических элементов не рябит в глазах, а с точки зрения информативности эта схема вполне понятна и доступна конечному пользователю. Если для каждой операции процесса описать требования к ее выполнению текстом, то комбинируя табличную и графическую формы представления, можно вполне адекватно описать порядок исполнения процесса для сотрудников компании.

Рис. 2. Схема процесса в нотации «Простая блок-схема » в MS Visio (без движения документов, без использования блока «Решение»)

«Плюсы» и «минусы» графического представления процесса в форме, представленной на Рис. 2, показаны ниже.

«Простая блок-схема » в MS Visio (без движения документов, без использования блока «Решение»)

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

На Рис. 3 представлена схема процесса, сформированная в нотации «Процедура» среды моделирования Business Studio. Схема имеет несколько особенностей. Во-первых, блоки «Решение» использованы нестандартным образом — не как графический элемент для отображения вопроса и ветвления, а как полноценная операция процесса, связанная с принятием решений. В Business Studio «ромбик» обладает почти всеми атрибутами полноценного процесса, но не может быть декомпозирован (возможно, разработчики системы со временем сделают такую возможность). Использование «ромбика» (вместо четырехугольника) делает схему нагляднее. При этом в атрибуты «ромбика» можно внести любую текстовую информацию: описание, начало, завершение, требование к срокам и т. п.

Второй особенностью схемы процесса, представленной на Рис. 3, является применение стрелок. Для отображения последовательности операций можно использовать стрелку с одним наконечником — стрелку «предшествования». Для отображения движения документов можно использовать стрелку с двумя наконечниками. Однако в Business Studio можно обойтись использованием только одного типа стрелок — стрелками «предшествования». При этом к именованным стрелкам можно привязывать необходимое количество документов, которые определены в справочнике объектов деятельности.

Такой подход дает возможность:

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

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

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

Рис. 3. «Процедура» системы Business Studio (вариант с нетрадиционным использованием блоков «Решение»)

«Плюсы» и «минусы» графического представления процесса в форме, представленной на Рис. 3, показаны ниже.

«Процедура» системы Business Studio (вариант с нетрадиционным использованием блоков «Решение»)

В случае применения Business Studio, нотация «Процедура» может быть использована несколько по-разному. Автор статьи склоняется к подходу, представленному на Рис. 3.

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

Заметим, что схема процесса в нотации ARIS eEPC занимает существенно больше места, чем схемы, представленные на Рис. 1-3. Трудоемкость формирования такой схемы также существенно выше.

Рис. 4. Схема процесса в нотации ARIS eEPC (построена в Business Studio)

Схема процесса в нотации ARIS eEPC (построена в Business Studio)

В целом, если Вы не собираетесь покупать SAP R/3, то выбор и использование нотации ARIS eEPC не является, с точки зрения автора статьи, оптимальным решением. Стоит обратить внимание на более наглядные и интуитивно понятные исполнителям нотации описания процессов. Впрочем, кому-то нотация ARIS eEPC может показаться более наглядной и понятной. До определенной степени, это вопрос вкуса.

Описание процесса для целей последующей автоматизации

Интересно рассмотреть приведенный выше пример описания бизнес-процесса в случае, если он представлен в нотации BPMN 2.0. Это нотация предназначена для описания «исполняемых» процессов, т. е. процессов которые поддерживает система BPM.

Своим мнением об использовании BPMN 2.0. делится А. А. Белайчук — Генеральный директор компании «Бизнес-консоль»:

«На Рис. 5 изображен тот же процесс в нотации BPMN. Как мы видим, этот рисунок похож на Рис. 1: в нотации BPMN задачи изображаются прямоугольниками, развилки — ромбами, данные — пиктограммой, похожей на документ. Потоки управления — сплошные линии, потоки данных — пунктирные.

Надо учитывать, что на этой диаграмме задействована только малая часть нотации BPMN: только один вид развилок из 5 имеющихся в палитре, один вид задач из 8. Помимо более широкой палитры, эту нотацию отличает возможность моделировать не только изолированный поток работ, но также несколько процессов, взаимодействующих друг с другом через сообщения или данные. Кроме того, эта нотация более строгая: в ней определены не только значки, но и правила, по которым они могут сочетаться друг с другом. Необходимость таких правил диктуется тем, что нотация BPMN ориентирована не только на то, что ее будут читать люди, но и на непосредственное исполнение специальным программным обеспечением — „движком“ BPM-системы.

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

Рис. 5. Схема процесса в нотации BPMN 2.0

Практика жизни

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

Рис. 6. Примеры схемы процесса одной из компаний

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

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

Выводы

Итак, очевидно, что при описании процессов нужно стремиться к простоте и понятности для сотрудников.

Использование сложных, формализованных нотаций при описании процессов приводит к:

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

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

http://finexpert.ru/ — среда общения профессионалов http://bpm3.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. Общий вид диаграммы классов.

Лабораторная работа №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.

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

Диаграммы для представления (feo)

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

Все диаграммы имеют нумерацию. Контекстная диаграмма имеет номер А-0, декомпозиция контекстной диаграммы – номер А), остальные диаграммы-декомпозиции – номера по соответствующему узлу (например, А1, А2, А21 и т.д.).

Модель idef0 в ms Visio

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

Рассмотрим возможности проведения системного анализа в среде MSVisio.

На рис. 4.3. изображены основные элементы модели в соответствии со стандартом IDEF0.

Рисунок 4.3. Элемент IDEF0 в MS VISIO

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

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

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

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

Рабочее место ms Visio

MSVisioпозволяет строить различные диаграммы. Поэтому перед началом работы необходимо выбрать соответствующий тип диаграммы (см. рис. 2.4.).

Рисунок 4.4. Выбор средств моделирования

Рабочее место MS Visio выполнено в виде рабочего стола, состоящего из нескольких окон.

На рабочем столе размещены:

образцы объектов модели;

область для рисования.

Панель Меню MS Visio . Панель Меню MS VISIO соответствует стандартам Windows и обеспечивает доступ ко всем функциям MS VISIO. Некоторые из них:

Печать. Чтобы открыть окно печати, на панели Меню выберите File, затем Print.

Масштаб. На панели Меню выберите View, затем измените масштаб изображения для активной диаграммы или для всех диаграмм в модели на тот, который Вам нужен.

Стандартная панель инструментов. Стандартная панель инструментов (рис. 4.5) обеспечивает быстрый доступ к часто выполняемым задачам.

Рисунок 4.5. Панель инструментов MSVisio

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

Образцы объектов модели (рис. 4.6) обеспечивают стандартизацию как общего вида модели, так и каждого ее элемента.

Рис. 4.6. Образцы объектов модели

Область для рисования (рис. 4.7.) предназначена собственно для построения модели.

Рисунок 2.7. Область рисования модели

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

Microsoft Visio для образовательных учреждений. «Схема рабочего процесса. Тренинг "Описание бизнес-процессов в Microsoft Visio"

Критерии выбора

Автоматическое обновление моделей бизнес-процессов

Введение

Сравнение нотаций

Описание процесса для целей последующей автоматизации

Практика жизни

Выводы

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

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

Диаграммы для представления (feo)

Модель idef0 в ms Visio

Рабочее место ms Visio