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

Содержание:

ВВЕДЕНИЕ

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

В противном случае надо управлять вслепую, используя принцип «вдруг получится».

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

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

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

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

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

Объект исследования теория моделирования бизнес-процессов.

Предмет исследования – подходы к оптимизации бизнес-процессов.

Основными задачами работы являются:

– изучить теоретические понятия процессного подхода;

– рассмотреть инструментальные системы моделирования бизнес-процессов;

– описать методы моделирования бизнес-процессов;

– выполнить сравнительный анализ методологий процессного подхода;

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

Стоит отметить, что рассматриваемой тематикой занимались зарубежные и отечественные программисты и ученые: Джестон Д., Кубарева Е. Ю., Новиков С., Теличенко В. И. и многие другие.

1.Понятие процессного подхода

1.1. Предназначение бизнес-процессов, основные определения и классификация

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

В поисках новых путей для повышения эффективности бизнеса в начале 90-х годов ХХ века в США появилась парадигма организации бизнеса, ориентированная на процессы. В результате этого, в лексикон бизнеса, а также IT-технологий вошли термины:

– бизнес-процесс;

– реинжиниринг бизнеса;

– реинжиниринг бизнес-процессов;

– моделирование бизнес-процессов.

До этого момента непосредственно в бизнесе господствовали идеи функционального разделения труда:

– процесс создания некоторого продукта делился на несколько функций;

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

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

Эту идею еще в конце XVIII столетия впервые сформулировал экономист Адам Смит. На ее базе были созданы мануфактуры, что в XIX веке вытесняли ремесленные цеха, кустарное производство товаров.

А в начале XX века Г. Форд усовершенствовал указанную идею и создал конвейер на своих заводах, что позволило увеличить производительность труда. В настоящее время такие конвейеры существуют для многих отраслях промышленности.

Потом Альфред Стоун, директор компании "Дженерал Моторс", использовал идею разделения труда для управления крупным производством. А в начале 1990-х гг. М. Хаммер и Дж. Чампли предложили другую форму организации бизнеса, ориентированную на процессы (или бизнес-процессы).

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

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

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

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

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

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

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

Поэтому, самым первым шагом при реорганизации является описание процесса, как именно в данный момент работает предприятие.

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

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

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

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

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

Рис. 1. Поставщик – процесс – потребитель

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

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

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

– управление процессом позволяет создать основания для контроля за временем выполнения ресурсов и работ.

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

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

Понятие БП можно определить по-разному. Основным является следующее определение:

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

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

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

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

В настоящее время выделяют 3 основных группы процессов:

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

– процессы (или подпроцессы) подразделений, деятельность для которых ограничена рамками только одного функционального подразделения организации. Указанные процессы называются внутрифункциональными процессами:

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

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

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

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

В отношении к получению добавленной стоимости (ценности) услуги или продукта можно выделить такие классы процессов:

– основные БП (производство, маркетинг, поставки, сервисное обслуживание товаров).

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

– бизнес-процессы управления.

1.2. Управление бизнес-процессами

Рассмотрим модели управления БП, поскольку они применяются для реализации стратегии функционирования исследуемого предприятия.

Применение моделей непрерывного улучшения процессов (НУП) – цикла Шухарта-Деминга или же цикла PDC(S)A в разных областях деятельности способствует реализации эффективного управления данной деятельностью на основе системности.

Основоположник научной организации менеджмента и труда Фредерик Тейлор определял понятие управление БП следующей фразой «планируй-делай-смотри».

Американский ученый У. Шухарт впервые описал систему PDCA в 1938 г. в книге «Статистические методы и управление качеством». У. Деминг предлагал использовать PDCA в качестве основного метода достижения НУП. Им же введена модификация цикла PDCA – цикл PDSA (от слова «study» – изучать).

Цикл PDCA в себя включает:

– планирование (plan) – установление процессов и целей, необходимых для достижения эффекта, распределение необходимых ресурсов;

– выполнение (do) – осуществление разного рода запланированных мероприятий;

– проверка (check) – это сбор информации, а также контроль результата и анализ отклонений;

– воздействие (act) – это принятие мер для устранения причин отклонений от планированного результата.

На рисунке 2 приведен пример БП, управляемого на основании цикла PDCA.

Циклы управления БП отражают методику управления процессами организации, а непосредственно технологию управления БП определяет метод BPM.

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

Рис.2. Цикл Шухарта – Деминга

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

Системный подход позволяет:

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

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

– обеспечить понимание всех взаимосвязей между процессами указанной системы;

– проводить непрерывное совершенствование систем посредством измерения их и оценки;

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

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

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

В России для анализа и моделирования БП достаточно широко используются средства моделирования:

– Oracle Designer;

– Rational Rose;

– АllFusion Data Modeler;

– AllFusion Process Modeler;

– ARIS.

За рубежом, помимо уже упомянутых, активно применяются средства Ithink Analyst, System Architect, ReThink и прочие.

АllFusion Data Modeler и AllFusion Process Modeler (BPWin и ERWin) компании Соmputer Associates входят в пятерку ведущих производителей ПО, предлагая средства резервного копирования, моделирования, управления инфраструктурой предприятия, информационной безопасности и т.д. Пакет BPWin базируется на методологии IDEF, а также предназначен для процесса функционального моделирования, анализа деятельности предприятия:

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

Функциональная модель IDEF может отображать функциональную структуру объекта, то есть производимые им действия, связи между этими процессами.

Основными характеристиками для указанной модели являются:

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

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

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

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

– Входы бизнес-процесса – это продукт, который при выполнении процесса преобразуется непосредственно в выход.

Вход должен иметь всегда своего поставщика. К типичным входам процесса относятся:

– сырье;

– документация;

– материалы;

– персонал;

– полуфабрикаты;

– информация;

– услуги и т.п.

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

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

– готовая продукция;

– документация;

– информация;

– персонал;

– услуги и т.п.

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

К ресурсам процесса относятся:

– информация;

– оборудование;

– персонал;

– инфраструктура;

– программное обеспечение;

– транспорт;

– среда;

– связь и пр.

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

2.2. Нотации моделирования БП

На основе методологии SADT разработана методология IDEF0. Она была утверждена как федеральный стандарт США в 1992 г.

Методологию IDEF0 считают следующим этапом развития известного графического языка для описания функциональных систем под названием SADT.

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

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

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

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

Описание системы при помощи IDEF0 называется функциональной моделью.

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

При передаче информации о конкретной системе некоторым источником графического языка считается сама методология IDEF0.

Методология IDEF0 предписывает построение специальной иерархической системы под названием «диаграмма - единичное описание фрагментов системы».

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

Потом каждая подсистема разбивается далее на более мелкие до достижения нужного уровня подробности и однозначности моделирования системы.

В основе данной методологии лежат 4 основных понятия:

– функциональный блок;

– декомпозиция;

– интерфейсная дуга;

– глоссарий.

Функциональный блок (англ. Activity Box) представляется некоторой конкретной функцией в рамках рассматриваемой моделируемой системы. По требованиям стандартов название каждого такого функционального блока должно формулироваться в глагольном наклонении (к примеру, «производить услуги»).

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

Каждая из 4-х сторон функционального блока использует свое определенное значение (или роль), а также:

– верхняя сторона – "Управление";

– левая сторона – "Вход";

– правая сторона – "Выход";

– нижняя сторона – "Механизм".

Рис.3. Схема контекстной диаграммы

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

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

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

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

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

– "входящей";

– "исходящей";

– "управляющей".

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

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

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

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

Нотация поддерживает лишь определенный набор концепций, необходимый для моделирования БП.

Моделирование иных аспектов, кроме БП, находится вне зоны действия BPMN.

К примеру, моделирование следующих аспектов не будет описываться в BPMN:

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

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

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

– объекты потока управления, а именно действия, логические операторы, события;

– соединяющие объекты: поток сообщений, ассоциации, поток управления.

– роли: дорожки и пулы;

– артефакты: группы. текстовые аннотации, данные.

Элементы этих категорий позволяют выполнять построение простейшие диаграммы БП.

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

Объекты потока управления могут быть разделены на 3 основных типа:

• cобытия;
• действия;
• логические операторы.

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

– промежуточные;

– начальные;

– завершающие.

Начиная с BPMN 1.1 различают события обработки и генерации. Ниже представлена категоризация событий по типам (рисунки 4, 5).

Рис.4. Основные категории событий

Рис.5. Вспомогательные категории событий

Простые события – нетипизированные события, использующиеся, чаще всего, для указания на начало или окончание БП.

События-сообщения показывают получение или отправку сообщений в процессе выполнения БП.

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

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

События-отмены реагируют на отмену транзакций.

События-компенсации инициируют компенсацию и выполняют действия для компенсации.

События-условия позволяют интегрировать разные бизнес-правила в БП.

События-сигналы выполняют рассылку и принимают сигналы с нескольких процессов.

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

Составные события моделирует генерацию или моделирование одного события с множества.

3.Сравнение CASE-инструментов для моделирования БП

3.1.Программная среда StarUML

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

StarUML – это программный инструмент для моделирования, который поддерживает нотацию UML (Унифицированный язык для моделирования). StarUML ориентируется на UML последней версии и поддерживает 11 различных типов диаграмм, которые приняты в нотации UML 2.0.

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

Рисунок 6 – Интерфейс StarUML

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

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

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

ПО может также быть интегрировано с любыми внешними средствами инструментального направления.

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

Рассмотрим основные особенности ПО.

– Открытый формат программной модели. В отличие от других существующих программ, что используют собственные неэффективные типы файла модели, программа StarUML оперирует файлами в формате XML.

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

Заметим, что XML считается мировым стандартом, а это – большое преимущество, что гарантирует, что такие программные модели останутся очень полезными на долгое время.

– Применимость платформ и методологий StarUML применяет концептуальный подход, что применим к практически любым методологиям или процессам. Легко создаются не лишь модели под средства выполнения разработки для определенных платформ типа J2EE и .NET, но также и для иных основных структур моделей (к примеру, модель представления 4+1).

– Превосходная расширяемость. Практически все функции StarUML реализованы в полном соответствии с стандартом Microsoft COM. Тут может применяться практически любой язык, который имеет поддержку COM (Visual Basic, VB, Delphi, Java Script, C++, C# и т.п.), может использоваться, чтоб вызывать StarUML и разрабатывать интегрированные дополнения (так называемые, аддины).

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

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

– генерация исходных текстов с помощью разных языков программирования;

– выполнение конвертации исходных текстов в разные модели;

– выполнение импорта файлов ПО Rational Rose;

– реализация обмена модельной информацией с иными программными средствами;

– поддержка паттернов проектирования.

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

3.2.Программная среда UMLet

UMLet – надежная и удобная программная утилита для разработки различного рода моделей процессов и проектирования программных приложений на базе языка UML.

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

С ее применением можно быстро строить диаграммы UML, экспортировать диаграммы в разные форматы, сохранять их и разрабатывать новые средства UML.

Главное окно UMLet разбито на 3 области (рисунок 7): область диаграммы, свойства и палитра элементов.

Рисунок 7 – Интерфейс UMLet

В результате есть выбрать элемент с набора элементов, представленного на палитре, и его поместить в область диаграммы.

При этом, в области диаграммы располагаются разные объекты сообразно выполнения целевой модели.

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

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

Рисунок 8 – Добавление новых инструментов

Основное назначение UMLet – это быстрое создание UML-модели в очень сжатые сроки.

С данной целью в программе реализовывается стандартный набор элементов языка UML:

– пакеты;

– варианты использования;

– стереотипы;

– простые классы;

- абстрактные классы;

– текстовые комментарии и другое:

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

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

3.3.Программная среда Oracle Designer

Набор современных инструментальных средств с названием Oracle Designer использует решение для разработки разного рода систем корпоративного уровня. Окно Oracle Designer изображено на рисунке 9:

Рисунок 9 – Внешний вид ПО Oracle Designer

Oracle Designer может брать участие практически во всех фазах ЖЦ разработки любого ПО – от моделирования до внедрения программы.

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

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

С помощью методологии IDEF можно эффективно реализовать и анализировать модели для деятельности широкого спектра самых сложных систем в разных разрезах.

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

Необходимо учитывать также важные характеристики моделирования БД. В частности, к основным преимуществам моделирования БД относят:

– повышение скорости и качества производства продукции с снижением издержек;

– рост профессионализма персонала;

– повышение конкурентоспособности организации.

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

• Афонин, В.В. Моделирование систем: учебно-практическое пособие / В.В. Афонин, С.А. Федосин. - М.: Интуит, 2016. - 231 c.
• Бариленко В. В. Основы бизнес-анализа. - М.: КНОРУС, 2014. – 272 с.
• Белов, П.Г. Управление рисками, системный анализ и моделирование в 3 ч. часть 1: Учебник и практикум для бакалавриата и магистратуры / П.Г. Белов. - Люберцы: Юрайт, 2016. - 211 c.
• Бизнес-процессы. Моделирование, внедрение, управление / В.В. Репин. - М.: Манн, Иванов и Фербер, 2013. - 512 c.
• Головицына, М.В. Проектирование радиоэлектронных средств на основе современных информационных технологий: Учебное пособие / М.В. Головицына. - М.: Бином, 2016. - 503 c.
• Гома, Хассан UML. Проектирование систем реального времени, параллельных и распределенных приложений / Хассан Гома. - М.: ДМК Пресс, 2016. - 700 c.
• Данелян, Т. Я. Экономические информационные системы (ЭИС) предприятий и организаций / Т.Я. Данелян. - М.: Юнити-Дана, 2015. - 284 c.
• Долганова О.И. Моделирование бизнес-процессов Учебник и практикум для академического бакалавриата Долганова О.И., Виноградова Е.В., Лобанова А.М.  Учебник и практикум Издание  1.  М.: Юрайт,  2016. -289  с.
• Елизаров, И.А. Моделирование систем: Учебное пособие / И.А. Елизаров, Ю.Ф. Мартемьянов. - Ст. Оскол: ТНТ, 2013. - 136 c.
• Елиферов В.Г. Бизнес-процессы: регламентация и управление: учеб­ное пособие для студентов вузов / В.Г. Елиферов, В.В. Репин; Ин-т экономики и финансов «Университет». – М.: ИНФРА-М, 2013. – 319 с.
• Елиферов В.Г. Бизнес-процессы: регламентация и управление. — М.: ИНФРА-М, 2017. — 319 с.
• Емельянова, Н.З. Проектирование информационных систем: Учебное пособие / Н.З. Емельянова, Т.Л. Партыка, И.И. Попов. - М.: Форум, 2013. - 432 c.
• Емцева Е. Д. Моделирование и анализ бизнес-процессов: учеб. пособие [для студентов вузов, обуч. по спец. 080500.62 "Бизнес-информатика"] / Е. Д. Емцева, К. С. Солодухин, С. В. Кучерова ; Владивосток. гос. ун-т экономики и сервиса. - Владивосток : Изд-во ВГУЭС, 2013. - 76 с.
• Заботина, Н.Н. Проектирование информационных систем: Учебное пособие / Н.Н. Заботина. - М.: НИЦ ИНФРА-М, 2013. - 331 c.
• Зенков, В. В. Методы и алгоритмы компьютерной обработки геологической и маркшейдерской информации. Практика обработки заводских данных / В.В. Зенков, О.А. Поляков, В.Е. Юрченко. - М.: Ленанд, 2013. - 268 c.
• Йордон, Эдвард Объектно-ориентированный анализ и проектирование систем / Эдвард Йордон , Карл Аргила. - М.: ЛОРИ, 2014. - 264 c.
• Исаев, Г.Н. Проектирование информационных систем: Учебное пособие / Г.Н. Исаев. - М.: Омега-Л, 2013. - 424 c.
• Ланджер, Мария Создание электронных таблиц и диаграмм в Excel / Мария Ланджер. - М.: НТ Пресс, 2014. - 144 c.
• Ларман Применение UML и шаблонов проектирования / Ларман, Крэг. - М.: Вильямс, 2015. - 624 c.
• Ларман, Крэг Применение UML 2.0 и шаблонов проектирования. Введение в объектно-ориентированный анализ, проектирование и итеративную разработку / Крэг Ларман. - М.: Вильямс, 2013. - 736 c.