Для моделирования бизнес-процессов используется несколько различных методов, в основе которых лежит как структурный, так и объектно-ориентированный подходы к моделированию. Однако, классификация самих методов структурных и объектные довольно условной, поскольку наиболее развитые методы используют элементы обоих подходов. Кратко рассмотрим характеристики наиболее распространенных методов:
o метод функционального моделирования SADT (IDEF0)
o метод моделирования процессов IDEF3;
o моделирование потоков данных DFD;
o метод Ericsson-Penker;
o метод технологии Rational Unified Process.
Метод SADT (Structured Analysis and Design Technique) считается классическим методом подхода к управлению на основе процессов, базовым принципом которого является структуризация деятельности организации в соответствии с ее бизнес-процессами. Бизнес-модель соответствует следующим требованиям:
o верхний уровень модели отражает исключительно контекст системы — взаимодействие предприятия с внешней средой;
o второй уровень описывает основные виды деятельности предприятия — тематически сгруппированы бизнес-процессы;
o дальнейшая детализация бизнес-процессов осуществляется с помощью бизнес-функций и элементарных бизнес-операций, сгруппированных по определенным признакам;
o описание элементарной бизнес-операции происходит путем определения алгоритма ее выполнения.
Метод используется для моделирования искусственных систем средней сложности.
Метод моделирования IDEF3 — часть семейства стандартов IDEF; используется для моделирования последовательности выполнения действий и их взаимозависимостей в рамках процесса. Метод получил признание среди системных аналитиков как дополнение к методу функционального моделирования IDEF0.
Основой модели IDEF3 служит сценарий процесса, который отделяет последовательность действий и подпроцессов системы. Как и в методе IDEF0, основной единицей модели является диаграмма. Другим важным компонентом является действие или «единица работы» (Unit of Work), взаимодействие которых изображается с помощью связей.
Диаграммы потоков данных (Data Flow Diagrams — DFD) представляют собой иерархию функциональных процессов, связанных потоками данных. Цель такого представления заключается в демонстрации того, как каждый процесс преобразует свои входные данные в выходные и выявления связей между этими процессами.
В соответствии с методом, модель системы определяется как иерархия диаграмм потоков данных, основными компонентами которых являются:
o внешние объекты;
o системы и подсистемы;
o накопители данных;
o потоки данных.
Первый компонент представляет собой материальный объект или физическое лицо, являющееся источником или приемником информации; например: заказчики, персонал, поставщики, состав.
Метод ARIS (Architecture of Integrated Information System), представляет собой комплекс средств анализа и моделирования деятельности предприятия. Его методическую основу составляет совокупность различных методов моделирования, отражающих разные взгляды на системы. ARIS поддерживает четыре типа моделей, которые отражают различные аспекты исследуемой:
o организационные, представляющие структуру системы;
o функциональные, содержащие иерархию целей;
o информационные — отражают структуру всей информации, необходимой для реализации функций системы;
o модели управления, представляющие комплексный подход к реализации бизнес-процессов в рамках системы.
Для построения указанных типов моделей используются как собственные методы моделирования ARIS, так и различные известные методы и языки моделирования, в частности UML.
Авторы метода Ericsson-Penker создали свой профиль UML для моделирования бизнес-процессов — Ericsson-Penker Business Extensions, введя набор стереотипов, которые описывают основные категории бизнес-модели: процессы, ресурсы, правила и цели деятельности предприятия.
Язык UML используется также в методе, который является частью технологии Rational Unified Process (фирмы IBM). Этот метод направлен прежде всего на создание основы для формирования требований к ПО. Предусматривает построение двух базовых моделей:
o модели бизнес-процессов (Business Use Case Model)
o модели бизнес-анализа (Business Analysis Model).
Модель бизнес-процессов представляет собой расширение модели вариантов использования (Use Case) UML путем введения набора стереотипов — Business Actor (стереотип действующего лица) и Business Use Case (стереотип варианта использования). Действующими лицами могут быть акционеры, клиенты, поставщики, партнеры, потенциальные клиенты, местные органы власти, внешние системы, сотрудники тех подразделений организации, деятельность которых не учитывается в модели, и тому подобное.
Business Use Case определяется как описание последовательности действий (потока) в рамках определенного бизнес-процесса, дает результат для определенной действующего лица.
Источник: studbooks.net
Методы и методики моделирования бизнес-процессов
Для моделирования бизнес-процессов используется несколько различных методов, основой которых являются как структурный, так и объектно-ориентированный подходы к моделированию. Однако деление самих методов на структурные и объектные является достаточно условным, поскольку наиболее развитые методы используют элементы обоих подходов. К числу наиболее распространенных методов относятся [4, с. 5-28]:
метод функционального моделирования SADT (IDEF0);
метод моделирования процессов IDEF3;
моделирование потоков данных DFD;
метод моделирования, используемый в технологии Rational Unified Process
1. Метод SADT (Structured Analysis and Design Technique) считается классическим методом процессного подхода к управлению. Основной принцип процессного подхода заключается в структурировании деятельности организации в соответствии с ее бизнес-процессами, а не организационно-штатной структурой.
Метод SADT может использоваться для моделирования самых разнообразных процессов и систем. В существующих системах метод SADT может быть использован для анализа функций, выполняемых системой, и указания механизмов, посредством которых они осуществляются.
Метод SADT представляет собой совокупность правил и процедур, предназначенных дляпостроения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями.
Результатом применения метода SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга.
Одной из наиболее важных особенностей метода SADT является постепенное введение все больших уровней детализации по мере создания диаграмм, отображающих модель.
Рис. 2. Структура SADT-модели. Декомпозиция диаграмм
2. Метод моделирования процессов IDEF3
Метод моделирования IDEF3 предназначен для моделирования последовательности выполнения действий и взаимозависимости между ними в рамках процессов.
Как и в методе IDEF0, основной единицей модели IDEF3 является диаграмма. Другой важный компонент модели — действие, или в терминах IDEF3 «единица работы» (Unit of Work). Диаграммы IDEF3 отображают действие в виде прямоугольника. Действия именуются с использованием глаголов или отглагольных существительных, каждому из действий присваивается уникальный идентификационный номер.
Этот номер не используется вновь даже в том случае, если в процессе построения модели действие удаляется. В диаграммах IDEF3 номер действия обычно предваряется номером его родителя (рис. 3).
Рис. 3. Изображение и нумерация действия в диаграмме IDEF3
Существенные взаимоотношения между действиями изображаются с помощью связей. Все связи в IDEF3 являются однонаправленными, и хотя стрелка может начинаться или заканчиваться на любой стороне блока, обозначающего действие, диаграммы IDEF3 обычно организуются слева направо таким образом, что стрелки начинаются на правой и заканчиваются на левой стороне блоков. В табл. 1 приведены три возможных типа связей.
Таблица 1. Типы связей IDEF3
3. Диаграммы потоков данных DFD
Диаграммы потоков данных (Data Flow Diagrams- DFD) представляют собой иерархию функциональных процессов, связанных потоками данных. Цель такого представления — продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.
В соответствии с данным методом модель системы определяется как иерархия диаграмм потоков данных, описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи потребителю. Источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те, в свою очередь, преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям — потребителям информации.
Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы с внешними входами и выходами. Они детализируются при помощи диаграмм нижнего уровня. Такая декомпозиция продолжается, создавая многоуровневую иерархию диаграмм, до тех пор, пока не будет достигнут уровень декомпозиции, на котором детализировать процессы далее не имеет смысла.
Основными компонентами диаграмм потоков данных являются:
- * внешние сущности;
- * системы и подсистемы;
- * процессы;
- * накопители данных;
- * потоки данных.
- 4. Метод ARIS
Система ARIS (Architecture of Integrated Information System), разработанный германской фирмой IDS Scheer, представляет собой комплекс средств анализа и моделирования деятельности предприятия. Ее методическую основу составляет совокупность различных методов моделирования, отражающих разные взгляды на исследуемую систему. Одна и та же модель может разрабатываться с использованием нескольких методов, что позволяет использовать ARIS специалистам с различными теоретическими знаниями и настраивать его на работу с системами, имеющими свою специфику.
ARIS поддерживает четыре типа моделей, отражающих различные аспекты исследуемой системы:
- * организационные модели, представляющие структуру системы — иерархию организационных подразделений, должностей и конкретных лиц, связи между ними, а также территориальную привязку структурных подразделений;
- * функциональные модели, содержащие иерархию целей, стоящих перед аппаратом управления, с совокупностью деревьев функций, необходимых для достижения поставленных целей;
- * информационные модели, отражающие структуру информации, необходимой для реализации всей совокупности функций системы;
- * модели управления, представляющие комплексный взгляд на реализацию бизнес-процессов в рамках системы.
Для построения перечисленных типов моделей используются как собственные методы моделирования ARIS, так и различные известные методы и языки моделирования, в частности, UML.
Модели в ARIS представляют собой диаграммы, элементами которых являются разнообразные объекты — «функция», «событие», «структурное подразделение», «документ» и т.п. Между объектами устанавливаются разнообразные связи. Так, между объектами «функция» и «структурное подразделение» могут быть установлены связи следующих видов:
- * выполняет;
- * принимает решение;
- * участвует в выполнении;
- * должен быть проинформирован о результатах;
- * консультирует исполнителей;
- * принимает результаты.
Основная бизнес-модель ARIS — eEPC (extended Eventdriven Process Chain — расширенная модель цепочки процессов, управляемых событиями). В табл. 2 приводятся основные объекты, используемые в данной нотации.
Таблица 2. Объекты модели eEPC
Рис. 4. Модель eEPC
Основное достоинство метода ARIS заключается в его комплексности, которая проявляется во взаимосвязи между моделями различных типов. Метод ARIS позволяет описывать деятельность организации с разных точек зрения и устанавливать связи между различными моделями. Однако такой подход трудно реализуем на практике, поскольку влечет за собой большой расход ресурсов (человеческих и финансовых) в течение длительного времени. Кроме того, инструментальная среда ARIS достаточно дорогостояща и сложна в использовании.
5. Метод Ericsson-Penker представляет интерес прежде всего в связи с попыткой применения языка объектного моделирования UML (изначально предназначенного для моделирования архитектуры систем ПО) для моделирования бизнес-процессов. Это стало возможным благодаря наличию в UML механизмов расширения.
Механизмы расширения UML предназначены для того, чтобы разработчики могли адаптировать язык моделирования к своим конкретным нуждам, не меняя при этом его метамодель.
Рис. 5. Метамодель категорий бизнес-модели
Наличие механизмов расширения принципиально отличает UML от таких средств моделирования, как IDEF0, IDEF1X, IDEF3, DFD и др. Перечисленные языки моделирования можно определить как сильно типизированные (по аналогии с языками программирования), поскольку они не допускают произвольной интерпретации семантики элементов моделей. UML, допуская такую интерпретацию (в основном за счет стереотипов), является слабо типизированным языком. К его механизмам расширения относятся:
- * стереотипы;
- * тегированные (именованные) значения;
- * ограничения.
Стереотип — это новый тип элемента модели, который определяется на основе уже существующего элемента. Стереотипы расширяют нотацию модели, могут применяться к любым элементам модели и представляются в виде текстовой метки или пиктограммы.
Именованное значение — это пара строк «тег = значение» или «имя = содержимое», в которых хранится дополнительная информация о каком-либо элементе системы, например, время создания, статус разработки или тестирования, время окончания работы над ним и т.п.
Ограничение — это семантическое ограничение, имеющее вид текстового выражения на естественном или формальном языке (OCL — Object Constraint Language), которое невозможно выразить с помощью графической нотации UML.
Авторы метода Ericsson-Penker создали свой профиль UML для моделирования бизнес-процессов под названием Ericsson-Penker Business Extensions, введя набор стереотипов, описывающих процессы, ресурсы, правила и цели деятельности организации.
Метод использует четыре основные категории бизнес-модели:
- * Ресурсы — различные объекты, используемые или участвующие в бизнес-процессах (люди, материалы, информация или продукты). Ресурсы структурированы, взаимосвязаны и подразделяются на физические, абстрактные, информационные и человеческие.
- * Процессы — виды деятельности, изменяющие состояние ресурсов в соответствии с бизнес-правилами.
- * Цели — назначение бизнес-процессов. Цели могут быть разбиты на подцели и соотнесены с отдельными процессами. Цели достигаются в процессах и выражают требуемое состояние ресурсов. Цели могут быть выражены в виде одного или более правил.
- * Бизнес-правила — условия или ограничения выполнения процессов (функциональные, поведенческие или структурные). Правила могут диктоваться внешней средой (инструкциями или законами) или могут быть определены в пределах бизнес-процессов. Правила могут быть определены с использованием языка OCL, который является частью стандарта UML.
Все эти категории связаны между собой: правило может определять способ структурирования ресурсов, ресурс назначается конкретному процессу, цель связана с выполнением конкретного процесса.
Основной диаграммой UML, используемой в данном методе, является диаграмма деятельности. Основным элементом диаграммы является деятельность (activity). Деятельность изображается в виде закругленного прямоугольника с текстовым описанием. Любая диаграмма деятельности должна иметь начальную точку, определяющую начало потока событий. Конечная точка необязательна.
На диаграмме может быть несколько конечных точек, но только одна начальная.
6. Метод моделирования, используемый в технологии Rational Unified Process
Язык UML используется также в методе моделирования бизнес-процессов, являющемся частью технологии Rational Unified Process компании IBM Rational Software. Этот метод, направленный прежде всего на создание основы для формирования требований к ПО, предусматривает построение двух базовых моделей:
- * модели бизнес-процессов (Business Use Case Model);
- * модели бизнес-анализа (Business Analysis Model).
Модель бизнес-процессов — модель, описывающая бизнес-процессы организации в терминах ролей и их потребностей. Она представляет собой расширение модели вариантов использования (use case) UML за счет введения набора стереотипов — Business Actor (стереотип действующего лица) и Business Use Case (стереотип варианта использования).
Business Actor (действующее лицо бизнес-процессов) — это некоторая роль, внешняя по отношению к бизнес-процессам организации. Потенциальными кандидатами в действующие лица бизнес-процессов являются: акционеры, заказчики, поставщики, партнеры, потенциальные клиенты, местные органы власти, сотрудники подразделений организации, деятельность которых не охвачена моделью, внешние системы.
Список действующих лиц составляется путем ответа на следующие вопросы:
- * Кто извлекает пользу из существования организации?
- * Кто помогает организации осуществлять свою деятельность?
- * Кому организация передает информацию и от кого получает?
Business Use Case (вариант использования с точки зрения бизнес-процессов) определяется как описание последовательности действий (потока событий) в рамках некоторого бизнес-процесса, приносящей ощутимый результат конкретному действующему лицу. Это определение подобно общему определению бизнес-процесса, но имеет более точный смысл. В терминах объектной модели Business Use Case представляет собой класс, объектами которого являются конкретные потоки событий в рамках описываемого бизнес-процесса.
Данный метод концентрирует внимание в первую очередь на элементарных бизнес-процессах. Такой процесс можно определить как задачу, выполняемую одним человеком в одном месте в одно время в ответ на некоторое событие, приносящую конкретный результат и переводящую данные в некоторое устойчивое состояние (например, подтверждение платежа по кредитной карточке). Выполнение такой задачи обычно включает от пяти до десяти шагов и может занимать от нескольких минут до нескольких дней, но рассматривается как один сеанс взаимодействия действующего лица с исполнителями.
Каждый Business Use Case отражает цель или потребность некоторого действующего лица.
Описание Business Use Case представляет собой спецификацию (текстовый документ), которая, подобно обычному варианту использования, состоит из следующих пунктов:
- * наименование;
- * краткое описание;
- * цели и результаты (с точки зрения действующего лица);
- * описание сценариев (основного и альтернативных);
- * специальные требования (ограничения по времени выполнения или другим ресурсам);
- * расширения (исключительные ситуации);
- * связи с другими Business Use Case;
- * диаграммы деятельности (для наглядного описания сценариев — при необходимости).
Описание Business Use Case может сопровождаться целью процесса, которая так же, как и в методе ErikssonPenker, моделируется с помощью класса со стереотипом «goal», а дерево целей изображается в виде диаграммы классов.
Для каждого Business Use Case строится модель бизнес-анализа — объектная модель, описывающая реализацию бизнес-процесса в терминах взаимодействующих объектов (бизнес-объектов — Business Object), принадлежащих к двум классам — Business Worker и Business Entity.
Business Worker (исполнитель) — активный класс, представляющий собой абстракцию исполнителя, выполняющего некоторые действия в рамках бизнес-процесса. Исполнители взаимодействуют между собой и манипулируют различными сущностями, участвуя в реализациях сценариев Business Use Case. На диаграмме классов UML исполнитель представляется в виде класса со стереотипом «business worker».
Понятие Business Entity аналогично понятию сущности в модели «сущность-связь», за исключением того, что в данной модели не определяется поведение сущности, а в объектной модели сущность может иметь набор обязанностей. На диаграмме классов UML сущность представляется в виде класса со стереотипом «business entity».
Источник: studwood.net
VII Международная студенческая научная конференция Студенческий научный форум — 2015
Моделирование бизнес-процессов в условиях модернизации экономики и управления является актуальным направлением, способствующим оптимизации процессов деятельности организации и повышению результативности бизнеса [1].Говоря о моделировании бизнес-процессов, используют терминологию сразу нескольких областей знаний, относящихся к экономике, информатике, моделированию сложных систем.
Бизнес-процесс определяется как логически завершенная цепочка взаимосвязанных и повторяющихся видов деятельности, в результате которых ресурсы предприятия используются для переработки объекта (физически или виртуально) с целью достижения определенных измеримых результатов или создания продукции для удовлетворения внутренних или внешних потребителей.
Термин моделирование имеет два основных значения. Во-первых, под моделированием понимают процесс построения модели как некоего представления (образа) оригинала, отражающего наиболее важные его черты и свойства. Если же модель уже построена, то моделирование — это процесс исследования (анализа) функционирования системы, вернее, ее модели. Базовой целью моделирования бизнес-процессов является описание реального хода бизнес-процессов компании. При этом необходимо определить, что является результатом выполнения процесса, кем и какие действия выполняются, каков их порядок, каково движение документов в ходе выполнения процесса, а также насколько процесс надежен (вероятность неудачного выполнения) и как он может быть расширен/модифицирован в будущем.
Обеспечить прозрачность хода бизнес-процессов важно потому, что только в этом случае владелец бизнес-процесса (сотрудник компании, управляющий ходом бизнес-процесса и несущий ответственность за его результаты и эффективность), бизнес-аналитик, руководство и другие заинтересованные стороны будут иметь ясное представление о том, как организована работа. Понимание хода существующих бизнес-процессов дает возможность судить об их эффективности и качестве и необходимо для разработки поддерживающей бизнес ИТ-инфраструктуры. Успешная разработка прикладных систем, обеспечивающих поддержку выполнения бизнес-процессов от начала до конца, возможна лишь тогда, когда сами процессы детально ясны.
Моделью бизнес-процесса называется его формализованное (графическое, табличное, текстовое, символьное) описание, отражающее реально существующую или предполагаемую деятельность предприятия.
Для моделирования бизнес-процессов можно использовать различные методы [2]. Метод, или методология, моделирования включает в себя последовательность действий, которые необходимо выполнить для построения модели, т. е. процедуру моделирования, и применяемую нотацию (язык). Наиболее популярной методологией бизнес-моделирования является ARIS, но также известны Catalyst компании CSC, BusinessGenetics, SCOR (Supply ChainOperationsReference), POEM (ProcessOrientedEnterpriseModeling) и др. Язык моделирования имеет свой синтаксис (условные обозначения различных элементов и правила их сочетания) и семантику (правила толкования моделей и их элементов).В теории и на практике существуют различные подходы к построению и отображению моделей бизнес-процессов[6].
В роли объектов при моделировании бизнес-процессов компании могут выступать конкретные предметы или реальные сущности, например клиент, заказ, услуга и т. п.Каждый объект характеризуется набором атрибутов, значения которых определяют его состояние, а также набором операций для проверки и изменения этого состояния. Объектно — ориентированный подход предполагает вначале выделение объектов, а затем определение тех действий, в которых они участвуют. При этом различают пассивные объекты (материалы, документы, оборудование), над которыми выполняются действия, и активные объекты (организационные единицы, конкретные исполнители, программное обеспечение), которые осуществляют действия. Такой подход позволяет более объективно выделить операции над объектами и решить задачу о целесообразности использования этих объектов.Недостаток объектно-ориентированного подхода состоит в меньшей наглядности конкретных бизнес-процессов.
История моделирования бизнес-процессов насчитывает уже почти столетие, хотя бизнес-моделирование выделяется в самостоятельное научно-прикладное направление только к началу 1990-х гг. Большинство созданных и применяемых до этого момента методологий не предназначались специально для описания бизнес-процессов, а разрабатывались для моделирования сложных систем и проектирования программного обеспечения.
Развитие методов моделирования и автоматизации бизнес-процессов приняторазделять на три этапа, или три «волны». Началом каждой из них явился очередной всплескинтереса к повышению эффективности деятельности предприятий и процессному управлению,происходивший каждый раз на новом качественном уровне. Основные характеристики этихэтапов приведены в таблице 1 в сравнении с соответствующими стадиями развитияинформационных технологий и подходов к совершенствованию деятельности компании.
В период «первой волны» для моделирования бизнес-процессов используются блок-схемы, ориентированные графы, сети Петри, методологии SADT, IDEF, DFD. Блок-схемы на основе определенной в ГОСТ 19.701-90 нотации схем алгоритмов, программ, данных и систем (в англ. литературе — ANSI flowcharts) остаются и сегодня простейшим, но практически важным формальным графическим языком моделирования бизнес-процессов.
В 1980-х гг. предпринимаются первые попытки автоматизации бизнес-процессов путем реализации в программном обеспечении для управления документами — системах электронного документооборота — функций по отслеживанию последовательности выполняемых действий для автоматизации процедур утверждения и выпуска документов. Успех таких систем вдохновляет разработчиков ПО на распространение аналогичного подхода на автоматизацию других функциональных областей бизнеса.
Начало второго этапа ознаменовал выход книги М. Хаммера и Д. Чампи«Реинжиниринг корпорации: манифест революции в бизнесе», которая возродила в управленческой среде интерес к описанию и анализу бизнес-процессов с целью их радикальной перестройки — реинжиниринга. Реинжиниринг бизнес-процессов предполагает построение двух моделей бизнес-процесса: «как есть» (англ. АSIS) и «как должно быть» (англ. TOBE), а затем внедрение последней на предприятии.
Как следующий шаг в автоматизации бизнес-процессов в 1990-х гг. появляются системы управления потоками работ WfMS (WorkflowManagementSystem) второго поколения, предназначенные для маршрутизации потоков работ любого типа в рамках бизнес-процессов компании. Эти системы снабжены средой разработчика, которая теоретически может использоваться для моделирования различных нестандартных бизнес-процессов, однако на практике в большинстве случаев внедрение нового или изменение имеющегося процесса требовало привлечения труда программистов. Еще более
ограниченные возможности по настройке и изменению процессов предоставляли поддерживающие управление потоками работ системы планирования ресурсов предприятия ERP (EnterpriseResourcePlanning). Внесение любых существенных изменений в бизнес- процесс превращалось в весьма дорогостоящий и долгосрочный проект по проектированию и разработке программного обеспечения, а модели бизнес-процессов, построенные аналитиками, использовались для более четкой формулировки требований, которые затем передавались программистам. В качестве примера методологии и средства автоматизации бизнес-процессов второго поколения можно назвать соответственно ARIS и распространенную ERP-систему SAP R/3.
Негибкость моделей и средств автоматизации, их неспособность обеспечить оперативное реагирование на постоянные изменения в бизнес-среде стали основными недостатками систем «второй волны», стимулировавшими разработку в начале 2000-х гг. методологий следующего — третьего — поколения. Манифестом «третьей волны» в моделировании бизнес-процессов можно по праву назвать книгу Г. Смита и П. Фингара «Управление бизнес-процессами: третья волна». На смену радикальному реинжинирингу приходит системное и «плавное» управление. Изменчивость бизнес-процессов, возможность их корректировки в ответ на изменения в бизнесе становятся главным критерием использования информационных технологий как средства, позволяющего получить преимущества на рынке.
Идея методологий и инструментов моделирования третьего поколения состоит в том, чтобы позволить руководству и сотрудникам компании создавать и самим внедрять новые процессы «на лету». Автоматизация процессов производится посредством так называемых систем управления бизнес-процессами BPMS (BusinessProcessManagementSystem), которые дают возможность непосредственно реализовывать бизнес-процессы в соответствии с построенной формальной моделью и не требуют разработки дополнительного программного обеспечения.
Для разработки понятных машине «исполняемых» моделей требуются более точные методы моделирования. К таким методам относятся языки моделирования на базе XML: BPML, BPEL, XPDL. Однако построение моделей непосредственно на этих языках неудобно для бизнес-пользователей. В этой связи большое внимание разработчики программного обеспечения уделяют средствам конвертирования графических моделей бизнес-процессов в исполняемые. Это позволяет бизнес-аналитику или менеджеру строить модели бизнес-процессов с использованием графической нотации, а затем преобразовывать построенную модель (пока нередко с помощью технического специалиста) в исполняемый вид.
«Третья волна» принесла в моделирование бизнес-процессов стремление к стандартизации.Методологии построения исполняемых моделей разрабатываются и выпускаются организациями постандартизацииимеждународнымиконсорциумами:
— OASIS (OrganizationfortheAdvancementofStructuredInformationStandards, основанав 1993 г.) выпускаетспецификацииebXMLиBPEL, атакжеразличныестандартыдляэлектронногобизнесанабазеXMLивеб-сервисов;
— OMG (ObjectManagementGroup, осн. в 1989 г.) выпускаетстандартыBPMNиUML, атакжеMDAиCORBA;
— W3C (WorldWideWebConsortium, осн. в 1994 г.) выпускает стандарты WS-CDL, WSCI, а также спецификации XML, технологии веб-сервисов и многие другие;
— WfMC (WorkflowManagementCoalition, осн. в 1993 г.) выпускает стандарты Wf-XML и XPDL.
На современном этапе в круг задач моделирования и автоматизации бизнес-процессов все чаще включают автоматизацию взаимодействия предприятия с внешней средой. В модели бизнес-процесса отражают взаимодействие компании с различными внешними сущностями: клиентами, коммерческими партнерами, поставщиками, административными органами. При автоматизации процесса данные взаимодействия также стараются по возможности автоматизировать. Особенно активно развиваются технологии автоматизации межкорпоративного взаимодействия — бизнес-бизнес (англ. Business-to-Business, B2B).
Развитие сети Интернет послужило толчком к созданию новых методов и технологий в области электронного обмена данными. Одним из наиболее удачных методов электронного обмена является появившаяся в 1998 г. методология консорциума RosettaNet.
Данная технология описывает открытую платформу электронного взаимодействия, основанного на стандарте XML, и позволяет сторонам, участвующим во взаимодействии, обмениваться бизнес-информацией через Интернет. Первоначально стандарт был разработан для индустрии высоких технологий (информационные технологии и электроника), однако предложенный подход послужил основой механизмов взаимодействия предприятий и других отраслей. В рамках методологии RosettaNet разработаны стандарты более сотни процессов бизнес-взаимодействия между различными компаниями или подразделениями внутри одного предприятия. Эти стандартизованные процессы получили название процессов интерфейса взаимодействия с партнером (PartnerInterfaceProcess, PIP) и специфицируют транзакции между двумя бизнес-системами в форме диалога на основе стандарта XML.
Еще одной современной технологией автоматизации межкорпоративного взаимодействия является ebXML (ElectronicBusinessusingextensibleMarkupLanguage,ИСО 15000). Работа над технологией ebXML началась в 1999 г. по инициативе СЕФАКТ ООН (Центр ООН по поддержке процедур и практики управления, коммерции и транспорта) и консорциума OASIS, накопившего большой опыт в сфере организации ведения бизнеса в Интернете на базе XML. Целью данного проекта является разработка инфраструктуры электронного бизнеса — полного набора спецификаций, позволяющего осуществлять бизнес-взаимодействия через единообразную XML-среду. С появлением ebXML компании получили стандартизованный де-факто метод обмена данными и бизнес-сообщениями, а также единые условия информационной поддержки торговых отношений.
Архитектура ebXML объединяет спецификации формата сообщений, модели бизнес-процессов, пакет синтаксически нейтральных базовых компонентов и распределенные хранилища данных (репозитории). Стандарт ebXML получает все более широкое распространение с внедрением технологии веб-сервисов (WebServices).
Моделирование бизнес-процессов в компании может быть направлено на решение широкогокруга задач[10]:
— Определение результата бизнес-процесса и оценка его значения для бизнеса [4].
— Определение набора действий, составляющих бизнес-процесс.
— Определение порядка выполнения действий. Действия в рамках одного бизнес-процесса могут выполняться как последовательно, так и параллельно. Очевидно, что параллельное исполнение, если оно допустимо, позволяет сократить общее время выполнения процесса и, следовательно, повысить его эффективность.
— Разделение зон ответственности предполагает определение, а затем отслеживание, какой сотрудник или подразделение компании несет ответственность за выполнение того или иного действия или процесса в целом.
— Определение ресурсов, потребляемых бизнес-процессом. Точно зная, кто какие ресурсы использует и для каких операций, можно повысить эффективность использования ресурсов посредством планирования и оптимизации.
— Уяснение сути взаимодействия между участвующими в процессе сотрудниками и подразделениями компании и повышение эффективности коммуникации между ними[8].
— Определение движения документов в ходе процесса. Бизнес-процессы производят и потребляют различные документы (в бумажной или электронной форме). Важно разобраться, откуда и куда идут документы или информационные потоки, и определить, оптимально ли их движение и действительно ли все они необходимы.
— Определение потенциально узких мест и возможности для улучшения процесса, которые будут использованы позже для его оптимизации.
— Использование модели бизнес-процессов в качестве руководства для новых сотрудников.
— Эффективноепроведение автоматизации бизнес-процессов в целом или отдельных их шагов, включая автоматизацию взаимодействия с внешней средой — клиентами, поставщиками, партнерами [3].
— Описание деятельности предприятия в целом.
Модели бизнес-процессов применяются предприятиями для различных целей, главными из которых являются планирование и управление результатами бизнеса [5]. Графическая модель бизнес-процесса может служить для согласования действий между структурными единицами организации, оптимизации и совершенствования деятельности компании [7]. Исполняемые модели бизнес-процессов могут быть запущены на специальном программном обеспечении для автоматизации процесса непосредственно по модели.
Так как модели бизнес-процессов предназначены для широкого круга пользователей: бизнес-аналитиков, рядовых сотрудников, руководства компании, в большинстве своем не имеющих практических навыков по построению моделей, то целесообразно для их исполнения использовать информационные технологии [9].
1. Голичев В.Д., Голичева Н.Д., Гусарова О.М. и др. Актуальные вопросы экономики и управления в условиях модернизации. Коллективная монография. — Смоленск: Смолгортипография, 2014. — 212 с.
2. Гусарова О.М. Моделирование результатов бизнеса в менеджменте организации // Перспективы развития науки и образования. — Тамбов: Бизнес-Наука-Общество, 2014. — с. 42-43.
3. Гусарова О.М. Информационно-аналитические технологии моделирования деятельности организаций Смоленского региона. — Смоленск: Свиток, 2013. — 100 с.
4. Гусарова О.М. Моделирование как способ планирования и управления результатами бизнеса // Успехи современного естествознания. — № 11, 2014. — с. 88-92.
5. Гусарова О.М. Моделирование в принятии управленческих решений // Наука и образование: проблемы и перспективы развития: сборник научных трудов по материалам Международной научно-практической конференции. — Тамбов: Юком, 2014. — С. 41-42.
6. Гусарова О.М. Проблемы интеграции теории и практики моделирования результатов бизнеса // Экономика и образование: Вызовы и поиск решений: сборник научных трудов по материалам II Всероссийской (заочной) научно-практической конференции (Ярославль, 15 апреля 2014 г.) — Ярославль: Канцлер, 2014. — С.78-82.
7. Гусарова О.М., Журавлева М.А. Анализ и совершенствование деятельности акционерных обществ // Современные наукоемкие технологии. — 2014. — № 7-3. — С.10-12.
8. Гусарова О.М. Методы и модели прогнозирования деятельности корпоративных систем // Теоретические и прикладные вопросы образования и науки: сборник научных трудов по материалам Международной научно-практической конференции. — Тамбов: Юком, 2014. — С. 48-49.
9. Гусарова О.М. Компьютерные технологии моделирования социально-экономических процессов // Экономический рост и конкурентоспособность России: тенденции, проблемы и стратегические приоритеты: сборник научных статей по материалам Международной научно-практической конференции. — М.: Юнити-Дана, 2012. — С. 102-104.
10. Репин В.В. Бизнес-процессы. Моделирование, внедрение, управление. — М.: Манн, Иванов и Фербер, 2013. — 512 с.
Источник: scienceforum.ru
