Применение процессного подхода для оптимизации бизнес-процессов ( Понятие процессного подхода в управлении)

Содержание:

Введение

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

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

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

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

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

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

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

Основные вопросы техники описания БП хорошо изло­жены в различной методической литературе, что разработана для программных продуктов ARIS, BPWin и т.д. 

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

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

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

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

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

– IDEF;

– UML;

– BPMN.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

– 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, а также предназначен для процесса функционального моделирования, анализа деятельности предприятия[16]:

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

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

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

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

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

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

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

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

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

– сырье;

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

– материалы;

– персонал;

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

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

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

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

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

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

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

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

– персонал;

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

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

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

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

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

– персонал;

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

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

– транспорт;

– среда;

– связь и пр.

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

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

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

Окно программы показано на рисунке 1:

Рисунок 1 – Окно АllFusion Data Modeler

Основные возможности BPwin:

– поддерживает три стандартные нотации: IDEF0, DFD и IDEF3. Эти 3 основных ракурса позволяют описать предметную область наиболее точно и комплексно;

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

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

– интегрирован с ERwin, Paradigm Plus и др.;

– интегрирован с средством имитационного моделирования под названием Arena;

– содержит собственный генератор для отчетов.

Набор инструментальных средств под названием Oracle Designer предлагает решение для разработки систем корпоративного уровня для веб и клиент-серверных приложений [4].

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

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

Окно Oracle Designer показано на рисунке 2:

Рисунок 2 – Окно Oracle Designer

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

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

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

ARIS поддерживает 4 типа моделей,отражающие различные аспекты системы. Интерфейс системы показан на рисунке 3:

Рисунок 3 – Окно системы ARIS

Система ARIS представляет комплекс средств моделирования и анализа деятельности предприятия.

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

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

2.1. Моделирование в нотации IDEF

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

– глоссарий.

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

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

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

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

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

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

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

Рисунок 4 – Схема контекстной диаграммы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Глоссарий дополняет гармонично наглядный графический язык, при этом снабжая диаграммы самой необходимой информацией[9].

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

IDEF0 требует, чтобы в диаграммах было не менее 3 и не более 6 блоков. Эти ограничения также поддерживают сложность диаграмм, модели на уровне, который доступен для чтения, а также понимания и использования[18].

В IDEF0 различают 5 типов стрелок:

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

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

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

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

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

2.2. Моделирование в нотации BPMN

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

– начальные;

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

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

Рисунок 5 – Основные категории событий

Рисунок 6 – Вспомогательные категории событий

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 7 –Типы действий

Задание – это единица работы или элементарное действие в БП.

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

2.3. Моделирование в нотации UML

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

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

Унифицированный язык для объектно-ориентированного моделирования UML явился методом достижения компромисса между такими подходами [6].

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

Мощный толчок для разработки этого направления ИТ дало распространение ООП в конце 1980-х годов.

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

UML представляет собой объектно-ориентированный язык для моделирования, обладающий такими основными характеристиками [9]:

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

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

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

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

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

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

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

Ниже приводится назначение основных перечисленных диаграмм и моделей.

Диаграммы прецедентов –обобщенная модель функционирования систем в окружающей среде [2].

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

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

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

Диаграммы классов – это логическая модель для базовой структуры системы. Они отражают ее статическую структуру и связи между элементами.

Диаграммы базы данных (БД)– это модель структуры БД, отображает столбцы, таблицы, ограничения и т.д.

Диаграммы компонентов – модель иерархии подсистем. Они отражают физическое размещение БД, приложений или интерфейсов системы.

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

На рисунке 8 показаны отношения между разыми видами диаграмм UML.

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

Рисунок 8 – Взаимосвязь между UML-диаграммами

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

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

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

Прецедент – это законченная последовательность действий.

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

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

Ассоциация – это связь между элементами модели. На диаграмме представлена линией.

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

На диаграмме представляется с помощью стрелки.

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

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

Рисунок 9 – Общая диаграмма деятельности медицинского центра для обслуживания пациентов

Рисунок 10 – Модель бизнес-прецедентов для составляющих обслуживание пациента

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

Рисунок 11 –Диаграмма видов деятельности прецедента «Оказание медицинской помощи»

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

При написании второй части работы рассмотрены основные методологии и подходы для выполнения моделирования БП:

– нотация IDEF;

– нотация BPMN;

– нотация UML.

Заключение

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

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

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

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

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

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

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

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

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

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

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

Список использованной литературы

1. G. Reggio, M. Leotta, F. Ricca, D. Clerissi. What are the used UML diagrams? A Preliminary Survey. EESSMOD@MoDELS 2013. P. 3–12.
2. OMG Unified Modeling Language (OMG UML), Version 2.5, 2013. 786 p.
3. Афонин, В.В. Моделирование систем: учебно-практическое пособие / В.В. Афонин, С.А. Федосин. - М.: Интуит, 2016. - 231 c.
4. Бариленко В. В. Основы бизнес-анализа. - М.: КНОРУС, 2014. – 272 с.
5. Белов, П.Г. Управление рисками, системный анализ и моделирование в 3 ч. часть 1: Учебник и практикум для бакалавриата и магистратуры / П.Г. Белов. - Люберцы: Юрайт, 2016. - 211 c.
6. Бизнес-процессы. Моделирование, внедрение, управление / В.В. Репин. - М.: Манн, Иванов и Фербер, 2013. - 512 c.
7. Головицына, М.В. Проектирование радиоэлектронных средств на основе современных информационных технологий: Учебное пособие / М.В. Головицына. - М.: Бином, 2016. - 503 c.
8. Гома, Хассан UML. Проектирование систем реального времени, параллельных и распределенных приложений / Хассан Гома. - М.: ДМК Пресс, 2016. - 700 c.
9. Данелян, Т. Я. Экономические информационные системы (ЭИС) предприятий и организаций / Т.Я. Данелян. - М.: Юнити-Дана, 2015. - 284 c.
10. Долганова О.И. Моделирование бизнес-процессов Учебник и практикум для академического бакалавриата Долганова О.И., Виноградова Е.В., Лобанова А.М.  Учебник и практикум Издание  1.  М.: Юрайт,  2016. -289  с.
11. Елизаров, И.А. Моделирование систем: Учебное пособие / И.А. Елизаров, Ю.Ф. Мартемьянов. - Ст. Оскол: ТНТ, 2013. - 136 c.
12. Елиферов В.Г. Бизнес-процессы: регламентация и управление: учеб­ное пособие для студентов вузов / В.Г. Елиферов, В.В. Репин; Ин-т экономики и финансов «Университет». – М.: ИНФРА-М, 2013. – 319 с.
13. Елиферов В.Г. Бизнес-процессы: регламентация и управление. — М.: ИНФРА-М, 2017. — 319 с.
14. Емельянова, Н.З. Проектирование информационных систем: Учебное пособие / Н.З. Емельянова, Т.Л. Партыка, И.И. Попов. - М.: Форум, 2013. - 432 c.
15. Емцева Е. Д. Моделирование и анализ бизнес-процессов: учеб. пособие [для студентов вузов, обуч. по спец. 080500.62 "Бизнес-информатика"] / Е. Д. Емцева, К. С. Солодухин, С. В. Кучерова ; Владивосток. гос. ун-т экономики и сервиса. - Владивосток : Изд-во ВГУЭС, 2013. - 76 с.
16. Заботина, Н.Н. Проектирование информационных систем: Учебное пособие / Н.Н. Заботина. - М.: НИЦ ИНФРА-М, 2013. - 331 c.
17. Зенков, В. В. Методы и алгоритмы компьютерной обработки геологической и маркшейдерской информации. Практика обработки заводских данных / В.В. Зенков, О.А. Поляков, В.Е. Юрченко. - М.: Ленанд, 2013. - 268 c.
18. Йордон, Эдвард Объектно-ориентированный анализ и проектирование систем / Эдвард Йордон , Карл Аргила. - М.: ЛОРИ, 2014. - 264 c.
19. Исаев, Г.Н. Проектирование информационных систем: Учебное пособие / Г.Н. Исаев. - М.: Омега-Л, 2013. - 424 c.
20. Ланджер, Мария Создание электронных таблиц и диаграмм в Excel / Мария Ланджер. - М.: НТ Пресс, 2014. - 144 c.