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

Основными средствами и методами моделирования логистических и производственных процессов в настоящее время являются SCOR (Supply Chain Operation Reference-Model), ARIS (Architecture of Information Systems), UML (Unified Modeling Language), IDEF (Integration Definition for Function Modeling).
Они обладают различными возможностями и предназначением.

Разработка концепции ARIS началась в середине 80-х годов в Институте экономической информатики в университете Саарбрюкен (Германия) под руководством профессора А. В. Шеера [87, 88,176]. С момента опубликования первого издания «Architektur inlegrierter Informationssysteme — ARIS» в 1991 году идея документирования биз- нес-процессов с помощью стандартных программных продуктов на основе разработки их моделей вызвала большой интерес у практиков.

Созданная А. В. Шеером методология ARIS, использующая принципы оптимизации организационных изменений в рамках BPR (реинжиниринга бизнес-процессов), сохранения базы знаний организации, использования документации процессов для сертификации по ISO 9000 и определения их затрат, а также применения моделей для внедрения новых ИТ, нашла широкий отклик и поддержку множества предприятий.

Во многом это было вызвано сотрудничеством А. В. Шеера с SAP/R3. Ему удалось убедить руководство SAP, что внедрение и эксплуатация такой многофункциональной системы, как R3, требует надлежащей поддержки со стороны предпроектного моделирования процессов. Такая поддержка была реализована с помощью набора модулей ARIS for R3 для документирования и анализа результатов проекта Начало использования ARIS в проектах SAP в значительной степени определило дальнейшее направление развития и повышения значимости методологий моделирования процессов.

Архитектура методологии ARIS представляет четыре типа моделей, отражающих различные аспекты исследуемой системы: •

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

функциональные модели (иерархия целей с совокупностью не* обходимых для их достижения «деревьев» функций); •

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

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

Графически такой подход может быть представлен следующим образом (рис. 10).

Организационная модель

' С fCT Модель /•—\ Управленческая /—N Функциональ данных \—V модель \ V ная модель Рис. Ю. Взаимосвязь типов моделей, используемых в ARIS-архитеюуре

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

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

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

Другим подходом к решению задач комплексного обследования предприятий и моделирования сложных систем явилась разработка стандартов и методологии семейства IDEF, позволяющих эффективно отображать и анализировать модели деятельности подобных систем [70, 71, 176, 192]. При этом широта и глубина обследования процессов в системе определяются самим разработчиком, что позволяет не перегружать создаваемую модель излишними данными.

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

IDEF0 (методология функционального моделирования); •

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

IDEF1X (методология построения реляционных структур и баз данных); •

IDEF2 (методология динамического моделирования развития систем, построенные на базе «раскрашенных сетей Петри» (CPN — Color Petri Nets)), •

IDEF3 (методология докуменіирования процессов, происходящих Б системе, которая используется, например, при исследовании технологических процессов на предприятиях); •

IDEF4 (методология построения объект но-ориеитированных систем); •

IDEF5 (методология онтологического исследования сложных систем).

Наиболее часто на практике используется методология функционального моделирования IDEF0, в основе которого лежат понятия функционального блока (Activity Box), интерфейсной дуги (Airow), декомпозиции (Decomposition) и глоссария (Glossary) Функциональный блок графически изображается в виде прямоугольника (рис 11) и представляет собой некоторую конкретную функцию в рамках рассматриваемой системы

Рис. 11. Структура функционального блока

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

управление (например, технологический план), •

вход (полуфабрикат); •

выход (готовый продукт); •

механизм (цех, рабочий).

Интерфейсные дуги (потоки или стрелки) соответствуют элементу системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). В зависимости от того, к какой из сторон подходит данная интерфейсная дуга, она носит название «входящей», «исходящей» или «управляющей». Обязательное наличие управляющих интерфейсных дуг является одной из главных особенностей стандарта IDEF0

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

Этим достигается структурная целостность модели IDEF0.

Другим подходом к моделированию логистических и производственных процессов явилась разработка в середине 90-х годов методологии UML (Unified Modeling Language). Основателями данного подхода принято считать Д. Румбаха, И. Якобсона, Г. Буча [10, 72,80,84,187]. Разработка языка UML началась в компании Rational в 1995 году с объединения методов G. Booch и развивавшейся в то время техники ОМТ (Object Modeling Technique). Процесс разработки было решено сделать общедоступным. В1997 году созданная общими усилиями многих компаний спецификация языка была принята группой OMG (рабочей группой по развитию стандартов объектного программирования).

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

Важной особенностью методологии UML является поддержка моделирования систем реального времени. Изменения в любой из функциональных областей отражаются во всех относящихся к ней взаимосвязанных объектах. При разработке систем, использующих реляционные БД, на основании диаграммы классов создается физическая модель БД для хранения данных объектов постоянных классов. Все решения, связанные с построением объектно-ориентированной модели программной системы, здесь должны быть за- вершены. В течение стадии реализации модели, созданные на стадиях проектирования системы, переводятся в исходный код 3GLmin 4GL языков программирования и разрабатывается база данных системы.

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

SCOR-модель

Если рассмотренные выше методологии являются общими методами моделирования процессов, то модель SCOR была специально разработана для реализации SCM (управление логистическими цепями). Это было вызвано необходимостью создания методики моделирования SCM и одинакового понимания лежащих в основе этого метода процессов с последующей их оценкой. Создание стандартизированной модели процессов было инициировано Советом по цепям поставок (Supply Chain Council — SCC). SCC является инициативным объединением, которое было создано в 1996 году в США п ііасчитьівает более 800 предприятий-участников В 2005 году был создан Национальный совет по цепям поставок в Москве, являющийся членом Европейского совета по цепям поставок.

Цель совета SCC - разработка и техническое описание стандартных моделей процессов (SCOR: Supply Chain Operation Reference) и обмен информацией между предприятиями, включенными в логистическую цепь (ЛЦ). С помощью SCOR-моделей должны быть созданы единые, сравнимые и приспособленные для оценки модели процессов внутри ЛЦ. SCOR описывает процессы управления цепочками поставок и сравнивает их с данными бепч-маркинга (сравнение с эталоном) и функциями программного обеспечения. В качестве вспомогательного средства SCOR располагает инструкциями, стандартизированной терминологией и общими показателями для проведения бенч-маркинга ЛЦ.

Модель SCOR имеет трехуровневую структуру [63, 105, 135, 176, 190, 191, 196, 212, 221]. В модели первого уровня (рис. 12) принципиально различаются следующие основные виды деятельности и процессы: •

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

снабжение (описание процессов приобретения, получения, проверки и предоставления поступающих материалов); •

производство (все производственные процессы); •

поставка (определение спроса, управление заказами и процесс сбыта, включая управление складами и транспортом^.

Эти основные процессы описываются более детально на следующих уровнях. Так, на втором уровне происходит дифференциация по 30 категориям «типовых» процессов, которые затем на третьем уровне конфигурируются с помощью элементов процесса с учетом отраслевых стандартных рекомендаций. SCOR-модель позволяет определить процессы в Л Ц на оперативном уровне в виде ограниченных частных процессов и задокументировать как временную и логическую последовательность производственных циклов выполнения

3-2239 о

о»

!

<^Ч]пану\рова»^ие^>

С^Пяанирояание" *)

Поставщики Поставщик

пнутрен-яии или внешний

Рис. 12. Макроуровень SCOR-модели

Возврат ( . Возврат ^Возврат

і I

І і

Изготовитель Клиент Клиенты

внутренний или внешний

ЛО'НСТИКа Ст>

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

SCOR является описательной моделью, которая позволяет предприятию осуществить структурированный вход в проект создания ЛЦ (уровень 1), смоделировать настоящие и будущие ЛЦ на уровне бизнес-процессов н обеспечить сравнение каждого их элемента сданными бенч-маркинга (уровни 2-3), а также подготовить основу для реализации процессов с помощью конкретных ИТ

К недостаткам SCOR следует oiнести прежде всего •

ее ориентированность как объекта моделирования на отдельное предприятие, а не на ЛЦ, •

ограничение моделирования процессов планирования и организации (отсутствие фаз контроля и изменений), •

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

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

<< | >>
Источник: Иванов, Дмитрий Александрович. Логистика. Стратегическая кооперация. - М. : Вершина. - 176 с.. 2006

Еще по теме Концепции моделирования бизнес-процессов:

  1. Моделирование бизнес-процессов
  2. Г.1.1. Моделирование продуктов и бизнес-процессов
  3. Причины неудач проектов моделирования и реорганизации бизнес-процессов
  4. Репин В. В., Елиферов В. Г.. Процессный подход к управлению. Моделирование бизнес-процессов, 2013
  5. Методология комплексного моделирования бизнес-процессов «КоМПас»
  6. Состав этапов типового проекта моделирования и реорганизации бизнес-процессов организации
  7. Концепция моделирования финансовой сферы маркетинговых систем
  8. ГЛАВА 2. ПРОЦЕСС ИМИТАЦИОННОГО МОДЕЛИРОВАНИЯ
  9. Понятие метода моделирования процессов
  10. Моделирование процессов в нотации DFD
  11. 3.1. Концепции бизнеса
- Cвязи с общественностью - PR - Бренд-маркетинг - Деловая коммуникация - Деловое общение и этикет - Делопроизводство - Интернет - маркетинг - Информационные технологии - Консалтинг - Контроллинг - Корпоративное управление - Культура организации - Лидерство - Литература по маркетингу - Логистика - Маркетинг в бизнесе - Маркетинг в отраслях - Маркетинг на предприятии - Маркетинговые коммуникации - Международный маркетинг - Менеджмент - Менеджмент организации - Менеджмент руководителей - Моделирование бизнес-процессов - Мотивация - Организационное поведение - Основы маркетинга - Производственный менеджмент - Реклама - Сбалансированная система показателей - Сетевой маркетинг - Стратегический менеджмент - Тайм-менеджмент - Телекоммуникации - Теория организации - Товароведение и экспертиза товаров - Управление бизнес-процессами - Управление знаниями - Управление инновационными проектами - Управление качеством товара - Управление персоналом - Управление продажами - Управление проектами - Управленческие решения -