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

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

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

Обзор

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

По данным Ассоциации специалистов по управлению бизнес-процессами (ABPMP), моделирование бизнес-процессов является одной из дисциплин управления бизнес-процессами , которая включает в себя следующие пять дисциплин: ^[1] ^{(Глава 1.4 Структура CBOK®) ← автоматический перевод с немецкого языка}

Моделирование процессов
Анализ процессов (понимание процессов «как есть» и их соответствие целям компании – анализ бизнес-деятельности)
Проектирование процессов (редизайн – реинжиниринг бизнес-процессов – или редизайн бизнес-процессов – оптимизация бизнес-процессов)
Измерение эффективности процесса (можно сосредоточиться на факторах времени, стоимости, мощности и качества или на общем взгляде на потери )
Трансформация процессов (плановая, структурированная разработка, техническая реализация и перевод в текущую эксплуатацию)

Однако полностью раздельное рассмотрение дисциплин невозможно: моделирование бизнес-процессов всегда требует анализа бизнес-процессов для моделирования процессов «как есть» (см. раздел «Анализ бизнес-деятельности ») или спецификаций проектирования процессов для моделирования будущих процессов ( см. раздел «Анализ бизнес-деятельности»). см. разделы «Реинжиниринг бизнес-процессов» и «Оптимизация бизнес-процессов» ).

По мнению Германа Й. Шмельцера и Вольфганга Сессельмана , основное внимание в моделировании бизнес-процессов уделяется представлению потока действий (деятельности) , состоящего «из кросс-функциональной идентификации действий, добавляющих ценность, которые генерируют конкретные услуги, ожидаемые клиентом, и результаты которых имеют стратегическое значение для компании. Они могут выходить за пределы компании и затрагивать деятельность клиентов, поставщиков или даже конкурентов». ^[2] ^{(Глава 2.1 Отличия процессов от бизнес-процессов) ← автоматический перевод с немецкого}

Но также и другие качества (факты), такие как данные и бизнес-объекты (в качестве входов/выходов, формальные организации и роли (ответственные/подотчетные/консультируемые/информированные лица, см. RACI ), ресурсы и ИТ-системы , а также руководящие принципы /инструкции ( работа оборудование ), требования , показатели и т.д. могут быть смоделированы.

Чем больше этих характеристик включено в моделирование бизнес-процессов, тем лучше абстракция моделей бизнес-процессов отражает реальность – и тем более сложными становятся модели бизнес-процессов. «Чтобы уменьшить сложность и улучшить понятность и прозрачность моделей, рекомендуется использовать концепцию представления». ^[3]^{(Глава 2.4 Представления о моделировании процессов) ← автоматический перевод с немецкого} Также приводится краткое сравнение концепций взглядов пяти соответствующих немецкоязычных школ бизнес-информатики : 1) Августа В. Шеера, 2) Хуберта Остерле, 3) Отто К. Ферстля и Эльмара Дж. Синца, 4) Германа Геринга и 5) Андреас Гадач.

Термин « взгляды » ( Аугуст В. Шеер , Отто К. Ферстль и Эльмар Дж. Синц, Герман Геринг и Андреас Гадач) не используется единообразно во всех школах бизнес-информатики — альтернативными терминами являются измерения дизайна (Хуберт Остерле) или перспективы (Захман). ).

М. Роземанн, А. Швегманн и П. Дельфманн также видят недостатки в концепции представлений : «Можно создавать информационные модели для каждой перспективы отдельно и, таким образом, с частичной избыточностью. Однако избыточность всегда означает увеличение усилий по обслуживанию и ставит под угрозу согласованность моделей». ^[4] ^{(Глава 3.2.1 Актуальные взгляды на модели процессов) ← автоматический перевод с немецкого}

По словам Андреаса Гадача, моделирование бизнес-процессов понимается как часть управления бизнес-процессами наряду с определением процессов и управлением процессами . ^[3] ^{(Глава 1.1 Управление процессами) ← автоматический перевод с немецкого языка}

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

По данным Европейской ассоциации управления бизнес-процессами EABPM, «существует три различных типа сквозных бизнес-процессов:

Лидерские процессы;
Процессы исполнения и
Поддержка процессов». ^[1] ^{(Глава 2.4 Типы процессов) ← автоматический перевод с немецкого языка}

Эти три типа процессов можно выделить в каждой компании и почти без исключения используются на практике в качестве верхнего уровня структурирования моделей бизнес-процессов. ^[5] Вместо термина « процессы лидерства» термин «процессы управления» обычно используется . Вместо термина « процессы исполнения» термин «основные процессы» . широкое распространение получил ^[2] ^{(Глава 6.2.1 Цели и концепция) ← автоматический перевод с немецкого,}^[6] ^{(Глава 1.3 Понятие процесса) ← автоматический перевод с немецкого,}^[7] ^{(Глава 4.12.2 Различие между основными и вспомогательными целями) ← автоматический перевод с немецкого,}^[8] ^{(Глава 6.2.2 Идентификация и черновой вариант) ← автоматический перевод с немецкого языка}

Если затем основные процессы организуются/декомпозируются на следующем уровне управления цепочками поставок (SCM), управления взаимоотношениями с клиентами (CRM) и управления жизненным циклом продукта (PLM), стандартные модели крупных организаций и отраслевых ассоциаций, такие как модель SCOR, могут также быть интегрированы в моделирование бизнес-процессов.

История

Методы моделирования бизнес-процессов, такие как блок-схема , блок-схема функционального потока , диаграмма потока управления , диаграмма Ганта , диаграмма PERT и IDEF , появились с начала 20-го века. Диаграммы Ганта были одними из первых, появившихся примерно в 1899 году, блок-схемы — в 1920-х годах, блок-схемы функциональных потоков и PERT — в 1950-х годах, а диаграммы потоков данных и IDEF — в 1970-х годах. Среди современных методов — унифицированный язык моделирования и модель и нотация бизнес-процессов . Тем не менее, это лишь малая часть методологий, использовавшихся на протяжении многих лет для документирования бизнес-процессов. ^[9] Термин «моделирование бизнес-процессов» был придуман в 1960-х годах в области системной инженерии С. Уильямсом в его статье 1967 года «Моделирование бизнес-процессов улучшает административный контроль». ^[10] Его идея заключалась в том, что методы, позволяющие лучше понять системы физического контроля, можно аналогичным образом использовать и для бизнес-процессов . Лишь в 1990-е годы этот термин стал популярным.

В 1990-х годах термин «процесс» стал новой парадигмой производительности. ^[11] Компаниям было предложено мыслить процессами, а не функциями и процедурами . Процессное мышление рассматривает цепочку событий в компании от покупки до поставки, от получения заказа до продаж и т. д. Традиционные инструменты моделирования были разработаны для иллюстрации времени и затрат, тогда как современные инструменты ориентированы на кросс-функциональные действия. Число и важность этих межфункциональных видов деятельности значительно возросли из-за роста сложности и зависимости. Новые методологии включают в себя редизайн бизнес-процессов , инновации бизнес-процессов, управление бизнес-процессами, интегрированное бизнес-планирование и многое другое, «направленные на улучшение процессов во всех традиционных функциях, составляющих компанию». ^[11]

В области разработки программного обеспечения термин «моделирование бизнес-процессов» противопоставлялся обычному моделированию процессов программного обеспечения , стремясь больше сосредоточиться на состоянии практики во время разработки программного обеспечения . ^[12] В то время (начало 1990-х годов) все существующие и новые методы моделирования для иллюстрации бизнес-процессов были объединены как « языки моделирования бизнес-процессов ». ^{[ нужна ссылка ]}. В объектно-ориентированном подходе это считалось важным шагом в спецификации систем бизнес-приложений. Моделирование бизнес-процессов стало основой новых методологий, например, тех, которые поддерживали сбор данных , анализ потоков данных, диаграммы потоков процессов и средства отчетности. Примерно в 1995 году были представлены первые визуально ориентированные инструменты для моделирования и реализации бизнес-процессов.

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

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

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

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

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

Более подробно, цели моделирования бизнес-процессов могут включать в себя (сравните: Ассоциация специалистов по управлению бизнес-процессами (ABPMP) ^[1] ^{(Глава 3.1.2 Характеристики и свойства процесса) ← автоматический перевод с немецкого языка}):

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

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

Поскольку моделирование бизнес-процессов само по себе не вносит прямого вклада в финансовый успех компании, нет и мотивации к моделированию бизнес-процессов, исходя из важнейшей цели компании – намерения получить прибыль . Таким образом, мотивация компании к моделированию бизнес-процессов всегда вытекает из соответствующей цели. Михаэль Роземанн, Ансгар Швегманн и Патрик Дельфманн перечисляют ряд целей в качестве мотивации для моделирования бизнес-процессов:

Организационная документация с «целью повышения прозрачности процессов с целью повышения эффективности информирования о процессах» ^[4] ^{(Глава 3.2.1 Соответствующие взгляды на модели процессов) ← автоматический перевод с немецкого,}^[3] ^{(Глава 2.5.4 Области применения моделирования процессов на практике) ← автоматический перевод с немецкого} включая возможность создавать шаблоны процессов для перемещения или репликации бизнес-функций или цель создания полной модели компании
Процессно-ориентированная реорганизация , как в смысле «(революционной) реинжиниринга бизнес-процессов , так и в смысле постоянного (эволюционного) улучшения процессов ». ^[4] ^{(Глава 3.2.1 Актуальные взгляды на модели процессов) ← автоматический перевод с немецкого} с целью оценки уязвимости ^[3] ^{(Глава 2.5.4 Области применения моделирования процессов на практике) ← автоматический перевод с немецкого}оптимизация процесса (например, путем контроля и сокращения общего времени цикла ^[13] (TCT), через Кайдзен , Шесть Сигм и т. д.) или стандартизацию процессов
Непрерывное управление процессами , как «планирование, внедрение и контроль процессов, направленных на устойчивое развитие». ^[4] ^{(Глава 3.2.1 Актуальные взгляды на модели процессов) ← автоматический перевод с немецкого}
Сертификация согласно DIN ISO/IEC 9001 (или также согласно ISO/IEC 14001 , ISO/IEC 27001 и т. д.)
Бенчмаркинг , определяемый как «сравнение структур и производительности конкретной компании с выбранными внутренними или внешними ссылками. В контексте моделирования процессов это может включать сравнение моделей процессов (структурный бенчмаркинг) или сравнение ключевых показателей процесса». ^[4] ^{(Глава 3.2.1 Актуальные взгляды на модели процессов) ← автоматический перевод с немецкого}
Управление знаниями с «целью повышения прозрачности ресурсов знаний компании с целью улучшения процесса выявления, приобретения, использования, развития и распространения знаний» ^[4] ^{(Глава 3.2.1 Актуальные взгляды на модели процессов) ← автоматический перевод с немецкого}
Выбор программного обеспечения ERP , которое «часто документирует свою функциональность в форме эталонных моделей (специфического программного обеспечения), поэтому имеет смысл также использовать сравнение моделей процессов, специфичных для компании, с этими моделями, специфичными для программного обеспечения, для выбора программного обеспечения» ^[4] ^{(Глава 3.2.1 Соответствующие взгляды на модели процессов) ← автоматический перевод с немецкого,}< ^[3] ^{(Глава 2.5.4 Области применения моделирования процессов на практике) ← автоматический перевод с немецкого}
на основе модели Настройка , то есть «конфигурация готового коммерческого программного обеспечения», часто посредством «параметризации программного обеспечения посредством настройки эталонных моделей». ^[4] ^{(Глава 3.2.1 Соответствующие взгляды на модели процессов) ← автоматический перевод с немецкого,}^[3] ^{(Глава 2.5.4 Области применения моделирования процессов на практике) ← автоматический перевод с немецкого}
Разработка программного обеспечения с использованием процессов «описания требований к разрабатываемому программному обеспечению на концептуальном уровне как часть разработки требований ». ^[4]^{(Глава 3.2.1 Соответствующие взгляды на модели процессов) ← автоматический перевод с немецкого,}^[14] ^{(Глава 3. Путь к процессно-ориентированному прикладному ландшафту) ← автоматический перевод с немецкого,}^[3] ^{(Глава 2.5.4 Области применения моделирования процессов на практике) ← автоматический перевод с немецкого}
Управление рабочими процессами, для которого модели процессов являются «основой для создания экземпляров моделей рабочих процессов». ^[4] ^{(Глава 3.2.1 Актуальные взгляды на модели процессов) ← автоматический перевод с немецкого}
Моделирование с целью «исследования поведения системы с течением времени» и «выявления слабых мест, которые не могут быть выявлены с помощью чистого модельного подхода». ^[4] ^{(Глава 3.2.1 Актуальные взгляды на модели процессов) ← автоматический перевод с немецкого}

Реинжиниринг бизнес-процессов (BPR)

В рамках обширной исследовательской программы, начатой в 1984 году в Массачусетском технологическом институте подход к реинжинирингу процессов под названием «Менеджмент в 1990-е годы», в начале 1990-х годов появился . Программа исследований была разработана для изучения влияния информационных технологий на то, как организации смогут выжить и процветать в конкурентной среде 1990-х годов и позже. В итоговом отчете Н. Венкат Венкатраман ^[15] суммирует результат следующим образом: Наибольшего увеличения производительности можно достичь, когда новые процессы планируются параллельно с информационными технологиями.

Этот подход был поддержан Томасом Х. Давенпортом. ^[16] ^{(Часть I: Структура процессных инноваций, Глава: Введение)} а также Майкл М. Хаммер и Джеймс А. Чампи ^[17] и превратили его в реинжиниринг бизнес-процессов (BPR), как мы его понимаем сегодня, согласно которому бизнес-процессы фундаментально реструктурируются для достижения улучшения измеримых показателей эффективности, таких как затраты, качество, обслуживание и время.

Реинжиниринг бизнес-процессов подвергался частичной критике за то, что он начинается с «нулевого поля» и, следовательно, не может быть реализован напрямую для существующих компаний. Герман Й. Шмельцер и Вольфганг Сессельман оценивают это следующим образом: «Критика BPR во многих отношениях носит академический характер... Некоторые из высказанных критических замечаний оправданы с практической точки зрения. Это включает указание на то, что чрезмерно радикальный Этот подход несет в себе риск неудачи. Это особенно проблематично, если организация и сотрудники не подготовлены должным образом к BPR». ^[2] ^{(Глава 6.2.1 Цели и концепция) ← автоматический перевод с немецкого языка}

По мнению Томаса Х. Давенпорта, высокоуровневый подход к BPR состоит из:

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

Сертификация системы менеджмента по ISO

Благодаря ISO/IEC 27001:2022 стандартные требования к системам менеджмента теперь стандартизированы для всех основных стандартов ISO и носят процессуальный характер.

Общие стандартные требования к системам менеджмента в отношении процессов

В стандартах ISO/IEC 9001, ISO/IEC 14001 , ISO/IEC 27001 это закреплено в главе 4.4 в каждом случае:

ИСО/МЭК 9001:2015 Раздел 4.4 Система менеджмента качества и ее процессы	ИСО/МЭК 14001:2015 Пункт 4.4. Системы экологического менеджмента	ИСО/МЭК 27001:2022 Пункт 4.4 Система управления информационной безопасностью

Каждый из этих стандартов требует от организации создания, внедрения, поддержания и постоянного улучшения соответствующей системы управления, «включая необходимые процессы и их взаимодействие». ^[18]^,^[19]^,^[20]

При определении стандартных требований к необходимым процессам и их взаимодействию ISO/IEC 9001 в пункте 4.4.1 более конкретен, чем любой другой стандарт ISO для систем менеджмента, и определяет, что «организация должна определять и применять процессы, необходимые для» ^[18] соответствующую систему управления во всей организации, а также перечисляет подробные требования в отношении процессов:

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

Кроме того, в пункте 4.4.2 стандарта ISO/IEC 9001 перечислены еще некоторыеподробные требования к процессам:

хранить документированную информацию
сохранять документированную информацию для правильной реализации

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

Особые стандартные требования к системам менеджмента в отношении документированной информации

В стандартах ИСО/МЭК 9001, ИСО/МЭК 14001, ИСО/МЭК 27001 требования к документированной информации закреплены в пункте 7.5 (детализированы в соответствующем стандарте в пунктах «7.5.1. Общие положения», «7.5.2. Создание и обновление» и «7.5.3. Контроль документированной информации»).

Стандартные требования ISO/IEC 9001, использованные здесь в качестве примера, включены в раздел «7.5.1. Общие положения».

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

требование в пункте «7.5.2. Создание и обновление»

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

и требуют в пункте «7.5.3. Контроль документированной информации»

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

В соответствии со стандартными требованиями,

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

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

Оптимизация бизнес-процессов

Герман Й. Шмельцер и Вольфганг Сессельман отмечают, что областью совершенствования трех методов, упомянутых ими в качестве примеров оптимизации процессов (контроль и сокращение общего времени цикла (TCT), Кайдзен и Шесть Сигм ), являются процессы: общее время цикла (TCT) — это бизнес-процессы (сквозные процессы) и подпроцессы, в Кайдзен — это этапы процесса и действия, а в Шести Сигмах — это подпроцессы, этапы процесса и действия. ^[2] ^{(Глава 6.3.1 Общее время цикла (TCT), КАЙДЗЕН и шесть сигм в сравнении) ← автоматический перевод с немецкого}

Что касается общего времени цикла (TCT), Герман Й. Шмельцер и Вольфганг Сессельман перечисляют следующие ключевые характеристики: ^[2] ^{(Глава 6.3.2 Общее время цикла (TCT)) ← автоматический перевод с немецкого}

Выявить барьеры, которые мешают ходу процесса
Устранить барьеры и заменить процессы
Измерьте эффект от устранения барьеров
Сравнение измеряемых переменных с целевыми значениями

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

При изучении инструментов Кайдзен изначально нет прямой связи с бизнес-процессами или моделированием бизнес-процессов. Однако Кайдзен и управление бизнес-процессами могут взаимно усиливать друг друга. В сфере управления бизнес-процессами цели Кайдзен напрямую вытекают из целей бизнес-процессов и подпроцессов. Эта связь гарантирует, что меры Кайдзен эффективно поддерживают общие бизнес-цели». ^[2] ^{(Глава 6.3.3 КАЙДЗЕН) ← автоматический перевод с немецкого}

«Шесть сигм» разработана для предотвращения ошибок и улучшения возможностей процесса , чтобы доля результатов процесса, соответствующих требованиям, составляла 6σ — или, другими словами, на каждый миллион результатов процесса происходит только 3,4 ошибки. Герман Й. Шмельцер и Вольфганг Сессельманн объясняют: «Компании часто сталкиваются со значительным сопротивлением на уровне 4σ, что делает необходимым перепроектирование бизнес-процессов в смысле реинжиниринга бизнес-процессов (проектирование для шести сигм)». ^[2] ^{(Глава 6.3.4 Шесть Сигм) ← автоматический перевод с немецкого} Для воспроизводимого измерения возможностей процесса требуется точное знание бизнес-процессов, а моделирование бизнес-процессов является подходящим инструментом для проектирования с использованием шести сигм. Таким образом, «Шесть сигм» использует моделирование бизнес-процессов в соответствии с SIPOC в качестве важной части методологии, а моделирование бизнес-процессов с использованием SIPOC зарекомендовало себя как стандартный инструмент «Шести сигм».

Моделирование внутрифирменных бизнес-процессов

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

Мартин Куглер в этом контексте перечисляет следующие требования к моделированию бизнес-процессов: ^[21] ^{(Глава 14.2.1 Требования к моделированию внутрифирменных бизнес-процессов) ← автоматический перевод с немецкого языка}

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

Темы

Анализ деловой активности

Определить рамочные условия

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

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

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

Эту стратегию долгосрочного успеха моделирования бизнес-процессов можно охарактеризовать с точки зрения рынка и/или подхода, основанного на ресурсах. Йорг Беккер и Фолькер Майзе объясняют: «В то время как с точки зрения рынка отрасль и поведение конкурентов напрямую определяют стратегию компании, ресурсно-ориентированный подход предполагает внутренний взгляд, анализируя сильные и слабые стороны компании и определяя направление развития». исходя из этого, разрабатываем стратегию». ^[7] ^{(Глава 4.6 Представление на основе ресурсов) ← автоматический перевод с немецкого языка} И далее: «Альтернативный характер, первоначально сформулированный в литературе между рыночным и ресурсным взглядами, теперь уступил место дифференцированной перспективе. Подход, основанный на ключевых компетенциях, рассматривается как важный вклад в объяснение потенциала успеха, который использоваться наряду с существующими рыночными подходами». ^[7]^{(Глава 4.7 Комбинирование просмотров) ← автоматический перевод с немецкого} Таким образом , в зависимости от стратегии компании карта процессов будет представлять собой модели бизнес-процессов с целью развития рынка, с целью оптимизации ресурсов или сбалансированным образом.

Определить бизнес-процессы

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

По мнению Европейской ассоциации управления бизнес-процессами (EABPM), установление общего понимания текущего процесса и его соответствие целям служит начальным шагом в проектировании процесса или его реинжиниринге». ^[1] ^{(Глава 4 Анализ процесса) ← автоматический перевод с немецкого}

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

Герман Й. Шмельцер и Вольфганг Сессельман , с другой стороны, обсуждают и оценивают критику радикального подхода к реинжинирингу бизнес-процессов (BPR) в литературе и «рекомендуют проводить анализ «как есть». Реорганизация должна знать текущие слабые места, чтобы иметь возможность их устранить. Результаты анализа также дают аргументы в пользу необходимости реинжиниринга процесса. Также важно знать исходную ситуацию для перехода от текущего состояния к целевому. Однако усилия по анализу следует держать в узких пределах. Результаты анализа также не должны слишком сильно влиять на редизайн». ^[2] ^{(Глава 6.2.2 Критическая оценка БПР) ← автоматический перевод с немецкого}

Структурируем бизнес-процессы – построение карты процессов

Тимо Фюерманн объясняет: «После того как бизнес-процессы идентифицированы и названы, они теперь объединены в обзор. Такие обзоры называются картами процессов». ^[22] ^{(Глава 2.4 Создание карты процесса) ← автоматический перевод с немецкого}

Пример **карты процессов** для рыночно ориентированной компании

Йорг Беккер и Фолькер Майзе приводят следующий список мероприятий по структурированию бизнес-процессов:

«Перечень основных процессов,
Определение границ процесса,
Определение стратегической значимости каждого процесса,
Анализ необходимости улучшения процесса и
Определение политической и культурной значимости процесса» ^[7] ^{(Глава 4.10 Определение структуры процесса) ← автоматический перевод с немецкого}

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

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

Пример **карты процессов** для ресурсоориентированной компании

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

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

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

При дифференцированном взгляде, без четкого акцента на взгляде на рынок или на взгляде на ресурсы, основные бизнес-процессы обычно делятся на CRM, PLM и SCM.

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

Пример **карты процессов** для компании, ориентированной на ценность

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

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

Результатом структурирования бизнес-процессов компании является карта процессов (представленная, например, в виде диаграммы цепочки создания стоимости ). Герман Й. Шмельцер и Вольфганг Сессельманн добавляют: «Между бизнес-процессами существуют связи и зависимости. Они основаны на передаче услуг и информации. Важно знать эти взаимосвязи, чтобы понимать, управлять и контролировать бизнес-процессы. ." ^[2] ^{(Глава 2.4.3 Карта процесса) ← автоматический перевод с немецкого языка}

Определение бизнес-процессов

Определение разработки продукта

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

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

для компании

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

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

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

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

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

Разъясняя этот момент, Йорг Беккер и Фолькер Майзе поясняют, что коммуникационная стратегия в рамках инициативы по организационному проектированию должна быть направлена на получение поддержки со стороны членов организации для запланированных структурных изменений. Стоит отметить, что моделирование бизнес-процессов обычно предшествует оптимизации бизнес-процессов, которая влечет за собой реконфигурацию организации процессов – факт, хорошо понятный заинтересованным сторонам. Следовательно, коммуникационная стратегия должна быть сосредоточена на том, чтобы убедить членов организации одобрить запланированные структурные изменения». ^[7] ^{(Глава 4.15 Влияние на разработку нормативной базы) ← автоматический перевод с немецкого языка} Однако в случае значительного сопротивления для определения бизнес-процессов можно также использовать внешние знания.

Общая идентификация процесса и индивидуальная идентификация процесса

Йорг Беккер и Фолькер Мейзе упоминают два подхода ( общая идентификация процессов и идентификация отдельных процессов ) и утверждают следующее об общей идентификации процессов: «В общем определении процесса предполагается, что существуют базовые, общезначимые процессы, одинаковые во всех компаниях. ." Далее говорится: «Детальные эталонные модели также могут использоваться для общей идентификации процессов. Они описывают отраслевые или прикладные системные процессы организации, которые еще необходимо адаптировать к индивидуальному случаю, но уже согласованы в своей структуре. ." ^[7] ^{(Глава 4.11 Общая идентификация процесса) ← автоматический перевод с немецкого языка}

Йорг Беккер и Фолькер Майзе говорят об идентификации отдельных процессов следующее: «При идентификации индивидуальных или единичных процессов предполагается, что процессы в каждой компании различаются в зависимости от потребностей клиентов и конкурентной ситуации и могут быть идентифицированы индуктивно на основе индивидуальной проблемы. ситуация». ^[7] ^{(Глава 4.12 Идентификация индивидуального процесса) ← автоматический перевод с немецкого языка}

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

Дальнейшее структурирование бизнес-процессов

Пример декомпозиции бизнес-процесса на подпроцессы – дополненные вехами, бизнес-единицами, объектами данных и ИТ-системами

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

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

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

Результатом дальнейшего структурирования бизнес-процессов обычно является иерархия подпроцессов, представленная в виде диаграмм цепочек создания стоимости. Обычно не все бизнес-процессы имеют одинаковую глубину декомпозиции. В частности, бизнес-процессы, которые не связаны с безопасностью, не являются затратоемкими и не способствуют достижению операционной цели, разбиваются на гораздо меньшую глубину. Аналогично, в качестве предварительного этапа декомпозиции процесса, запланированного (намного) позже, общее понимание может быть сначала достигнуто с использованием более простых/менее сложных средств, чем диаграммы цепочки создания стоимости , например, с помощью текстового описания или диаграммы-черепахи. ^[22] ^{(Глава 3.1 Определение деталей процесса) ← автоматический перевод с немецкого языка} (не путать с изображением черепахи !).

Назначение ответственности за процесс

Образец пирамиды ответственности процессов

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

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

Проектирование технологических цепочек

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

Как моделировать и быть моделингом

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

«как есть» Моделирование

Ансгар Швегманн и Михаэль Ласке поясняют: «Определение текущего статуса является основой для выявления слабых мест и локализации потенциала для улучшения. Например, можно выявить такие слабые места, как организационные перерывы или недостаточное проникновение ИТ». ^[23] ^{(Глава 5.1 Цель моделирования ) ← автоматический перевод с немецкого языка}

моделирования говорят следующие недостатки Против :

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

Эти аргументы особенно весомы, если реинжиниринг бизнес-процессов (BPR) все равно планируется.

Ансгар Швегманн и Михаэль Ласке также перечисляют ряд преимуществ моделирования « как есть »: ^[23] ^{(Глава 5.1 Цель моделирования «как есть») ← автоматический перевод с немецкого}

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

Можно найти и другие преимущества, например

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

Быть моделью

Марио Спек и Норберт Шнетгоке определяют цель моделирования следующим образом: «Целевые процессы основаны на стратегических целях компании. Это означает, что все подпроцессы и отдельные виды деятельности компании должны анализироваться с учетом их целевых показателей. Поэтому подпроцессы или виды деятельности, которые не могут быть идентифицированы как добавляющие ценность и не служат хотя бы одной неденежной корпоративной цели, должны быть исключены из бизнес-процессов». ^[8] ^{(Глава 6.2.3 Сбор и моделей документирование )}

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

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

Модель бизнес-процесса, созданная методом «как есть» или «будет моделировать», состоит из:

Подпроцессы

Делимитация

Разбивка бизнес-процесса Процесс продаж на подпроцессы по этапам

Говорят, что Август В. Шеер сказал в своих лекциях: «Процесс есть процесс есть процесс». Это предназначено для выражения рекурсивности термина, поскольку почти каждый процесс можно разбить на более мелкие процессы (подпроцессы). В этом отношении такие термины, как бизнес-процесс , основной процесс , подпроцесс или элементарный процесс, являются лишь отчаянной попыткой обозначить уровень декомпозиции процесса. Поскольку не существует универсального соглашения о детализации бизнес-процесса , основного процесса , подпроцесса или элементарного процесса , эти термины не имеют универсального определения, но могут быть поняты только в контексте соответствующей модели бизнес-процесса.

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

Дерево функций с фрагментами типичных действий компании, *конвейера продаж .* отмечены соответствующие функции

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

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

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

Использование

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

Рабочий процесс

Рабочий процесс — это представление последовательности задач, заявленной как работа человека, простого или сложного механизма, группы людей, ^[24] организации персонала или машин (включая ИТ-системы). Таким образом, рабочий процесс всегда находится на уровне элементарного процесса. Рабочий процесс можно рассматривать как любую абстракцию реальной работы, разделенную на совместную работу, разделение работы или другие типы упорядочения. В целях контроля рабочий процесс может представлять собой представление реальной работы в выбранном аспекте.

Функции ( Задачи )

Задачи элементарного процесса, последовательность задач, определяемая тремя разными подходами

Делимитация

Термин «функции» часто используется как синоним разграниченной корпоративной функции /области действия (activita), закрепленной за владельцем корпоративной функции , и атомарной деятельности (задачи) на уровне элементарных процессов . Чтобы избежать двойного значения термина « функция» , термин « задача» можно использовать для атомарных действий на уровне элементарных процессов в соответствии с именованием в BPMN. Современные инструменты также предлагают автоматическое преобразование задачи в процесс , так что можно в любой момент создать дальнейший уровень декомпозиции процесса, на котором задачу затем необходимо повысить до элементарного процесса .

Использование

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

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

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

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

Основные данные (артефакты)

Термин «основные данные» не определен ни The Open Group ( The Open Group Architecture Framework , TOGAF), ни Джоном А. Захманом (Zachman Framework), ни какой-либо из пяти соответствующих немецкоязычных школ бизнес-информатики: 1) Август В. Шеер , 2) Хуберт Остерле , 3) Отто К. Ферстль и Эльмар Дж. Синц, 4) Герман Геринг и 5) Андреас Гадач и обычно используется при отсутствии подходящего термина в литературе. Он основан на общем термине для данных , которые представляют собой базовую информацию об оперативно важных объектах и относятся к базовой информации, которая не является первичной информацией бизнес-процесса.

Для Августа В. Шеера из ARIS это будет основная информация о представлении организации, представлении данных, представлении функций и представлении производительности. ^[25] ^{(Глава 1. Видение: общий язык для ИТ и менеджмента) ← автоматический перевод с немецкого}

Для Андреаса Гадача из GPM ( G anzheitliche Prozess modellierung (немецкий язык) означает целостное моделирование процессов) это будет основная информация о представлении организационной структуры, представлении структуры деятельности, представлении структуры данных и представлении структуры приложения. ^[3] ^{(Глава 3.2 GPM – Целостное моделирование процессов) ← автоматический перевод с немецкого}

Для Отто К. Ферстла и Элмара Дж. Синца в SOM ( объекта модель семантического ) это . будет основная информация уровней «Бизнес-план» и «Ресурсы»

Основные данные могут быть, например:

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

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

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

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

Бизнес-процесс, ориентированный на артефакты

Модель бизнес-процессов, ориентированная на артефакты, стала целостным подходом к моделированию бизнес-процессов, поскольку она обеспечивает очень гибкое решение для сбора эксплуатационных характеристик бизнес-процессов. Особое внимание уделяется описанию данных бизнес-процессов, известных как «артефакты», путем характеристики объектов данных, имеющих отношение к бизнесу, их жизненных циклов и связанных с ними услуг. Подход к моделированию процессов, ориентированный на артефакты, способствует автоматизации бизнес-операций и поддерживает гибкость внедрения и развития рабочих процессов. ^[26]

Интеграция внешних документов и IT-систем

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

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

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

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

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

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

Консолидация модели

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

Ансгар Швегманн и Михаэль Ласке поясняют: «Объединение моделей разных моделирующих комплексов необходимо для того, чтобы получить интегрированную… модель». ^[23] ^{(Глава 5.2.4 Консолидация модели) ← автоматический перевод с немецкого языка} Они также перечисляют ряд аспектов, для которых важна консолидация моделей:

«Командам моделирования необходимо обеспечить гармонизацию моделей во время их создания, чтобы облегчить последующую консолидацию».
«Если проводится объектно-ориентированная декомпозиция предметной области, на ранней стадии необходимо проанализировать, существуют ли схожие структуры и процессы разных объектов».
«Если проводится функционально-ориентированная декомпозиция проблемной области, интерфейсы между смоделированными областями, в частности, должны быть гармонизированы».
«В целом, во время моделирования следует стремиться к единообразному уровню детализации моделей» (на каждом уровне декомпозиции), чтобы облегчить сопоставимость подмоделей и точное определение интерфейсов.
«После завершения работ по моделированию в коллективах отдельных модельных комплексов созданные частичные модели подлежат интеграции в общую модель».
«Чтобы облегчить отслеживание отображаемых процессов, имеет смысл явно смоделировать выбранные бизнес-операции, которые особенно важны для компании, и отобразить их на верхнем уровне. ... Например, также можно использовать цветовое кодирование. различать связанные организационные единицы». ^[23] ^{(Глава 5.2.4 Консолидация модели) ← автоматический перевод с немецкого языка}

Цепочки процессов и схемы управления потоками

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

Существенные детали цепочки (что предшественник доставляет преемнику?) указываются в интерфейсах процессов, если это предусмотрено.

Интерфейсы процесса

Интерфейсы процессов определяются для того, чтобы

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

Как правило, это что и его структура определяются требованиями в последующем процессе.

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

Поток процесса с интерфейсом к процессу обслуживания в синтаксисе EPC (вверху) и синтаксисе BPMN (внизу)

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

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

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

Интерфейсы могут определяться:

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

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

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

См. статью Управление бизнес-процессами.

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

Адаптация моделей процессов

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

Тип представления и обозначения

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

Техники моделирования

Существуют различные стандарты обозначений; наиболее распространенными являются:

Модель и нотация бизнес-процессов (BPMN), предложенная в 2002 году Стивеном А. Уайтом, опубликованная Инициативой по управлению бизнес-процессами - в июне 2005 года объединилась с Object Management Group.
Цепочка процессов, управляемых событиями (EPC), предложенная в 1992 году рабочей группой под руководством Августа-Вильгельма Шеера.
Диаграмма цепочки добавленной стоимости ( VAD ), для визуализации процессов преимущественно на высоком уровне абстракции.
Сеть Петри , разработанная Карлом Адамом Петри в 1962 году.
Планы последующих действий (например, в конкретной форме блок-схемы ), предложенные в 1997 году Фишерманнсом и Либелтом.
Модель HIPO , разработанная IBM примерно в 1970 году как средство проектирования и документирования программного обеспечения (в нетехнической, но бизнес-ориентированной форме).
Язык моделирования жизненного цикла (LML), первоначально разработанный руководящим комитетом LML и опубликованный в 2013 году.
Предметно-ориентированное управление бизнес-процессами (S-BPM)
Метод анализа информации на естественном языке с улучшением когнитивных функций (CogNIAM)
Диаграмма SIPOC, изобретенная в 1980-х годах как часть движения «Всеобщее управление качеством» , а затем принятая практиками бережливого управления и шести сигм.
Унифицированный язык моделирования (UML), предложенный в 1996 году Грэди Бучем , Иваром Джейкобсоном и Джеймсом Рамбо , постоянно пересматриваемый под эгидой OMG (обеспечивает расширения бизнес-процессов)
ICAM DEFinition ( IDEF0 ), разработанный для ВВС США в начале 1980-х годов.
Формализованная административная нотация (FAN) , созданная Пабло Якубом и Леонардо Майо в 1990-х годах.
Моделирование процессов по Харбариану (HPM)
Язык выполнения бизнес-процессов (BPEL), язык на основе XML, разработанный в 2002 году OASIS для описания и автоматизации бизнес-процессов.
Диаграмма черепахи (также метод черепахи, модель черепахи, метод 8W), простое, ясное и понятное графическое представление фактов о процессе.

Более того:

Анализ структуры связи , предложенный в 1989 году профессором Германом Кроллманном на факультете системного анализа Берлинского технического университета.
Расширенный язык бизнес-моделирования (xBML) ^[27] (кажется, устарело, так как компании-учредителя больше нет в сети) ^[28])
Обозначения от OMEGA (объектно-ориентированный метод моделирования и анализа бизнес-процессов, Объектно -ориентированный метод моделирования бизнес и анализа -процессов на немецком языке), представленные Утой Фарвинкель в 1995 году. ^[29]
Семантическая объектная модель ( SOM ), предложенная в 1990 году Отто К. Ферстлем и Элмаром Дж. Синцем.
ИЗОБРАЖЕНИЕ-Метод документирования и моделирования бизнес-процессов в государственном управлении
Диаграмма потока данных — способ представления потока данных через процесс или систему.
BPMN Этот метод используется в основном в , но также в SIPOC, диаграмме цепочки процессов ( PCD ) и других методах.
ProMet , набор методов для бизнес-инжиниринга
Диаграмма состояний , используемая для описания поведения систем.

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

Блок-схема, стандартизированная в стандарте DIN 66001 от сентября 1966 года и последний раз пересмотренная в декабре 1983 года или стандартизированная в ISO 5807 от 1985 года.
Диаграмма Насси-Шнейдермана или структурная диаграмма, предложенная в 1972/73 году Исааком Насси и Беном Шнейдерманом , стандартизированная в DIN 66261.

Модель бизнес-процессов и нотация (BPMN)

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

Модель и нотация бизнес-процессов (BPMN) — это графическое представление для определения бизнес-процессов в модели бизнес-процессов.

Первоначально разработанная Инициативой по управлению бизнес-процессами (BPMI), BPMN поддерживается Группой управления объектами (OMG) с момента слияния двух организаций в 2005 году. Версия 2.0 BPMN была выпущена в январе 2011 года. ^[30] после этого название было изменено на «Модель бизнес-процесса и нотация», чтобы отразить введение семантики выполнения, которая была введена наряду с существующими элементами обозначений и диаграмм. Хотя это спецификация OMG, BPMN также ратифицирован как ISO 19510. Последней версией является BPMN 2.0.2, опубликованная в январе 2014 года. ^[31]

Цепочка процессов, управляемая событиями (EPC)

Цепочка процессов, управляемая событиями (EPC), — это тип блок-схемы моделирования бизнес-процессов. EPC можно использовать для настройки выполнения планирования ресурсов предприятия , а также для улучшения бизнес-процессов . Его можно использовать для управления экземпляром автономного рабочего процесса при совместном использовании работы.

Метод цепочки событий, управляемых событиями, был разработан в рамках архитектуры интегрированных информационных систем (ARIS) Августом-Вильгельмом Шеером в Institut für Wirtschaftsinformatik, Universität des Saarlandes (Институт систем бизнес-информации при Университете Саара) в начале 1990-е годы. ^[32]

сеть Петри

Сеть Петри , также известная как сеть мест/переходов (PT-сеть), является одним из нескольких математического языков моделирования для описания распределенных систем . Это класс дискретно-событийной динамической системы . Сеть Петри представляет собой ориентированный двудольный граф , имеющий два типа элементов: места и переходы. Элементы места изображаются в виде белых кружков, а элементы перехода — в виде прямоугольников. Место может содержать любое количество жетонов, обозначенных черными кружками. Переход разрешен, если все места, подключенные к нему в качестве входов, содержат хотя бы один токен. Некоторые источники ^[33] утверждают, что сети Петри были изобретены в августе 1939 года Карлом Адамом Петри — в возрасте 13 лет — с целью описания химических процессов.

Подобно отраслевым стандартам, таким как UML диаграммы деятельности , модель и нотация бизнес-процессов , а также цепочки процессов, управляемых событиями , сети Петри предлагают графическую нотацию для пошаговых процессов, включающих выбор, итерацию и одновременное выполнение . В отличие от этих стандартов, сети Петри имеют точное математическое определение семантики их выполнения и хорошо развитую математическую теорию анализа процессов. ^{[ нужна ссылка ]}.

Блок-схема

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

На блок-схеме шаги показаны в виде блоков разных типов, а их порядок показан путем соединения блоков стрелками. Это схематическое представление иллюстрирует модель решения данной проблемы . Блок-схемы используются при анализе, проектировании, документировании или управлении процессом или программой в различных областях. ^[34]

Иерархическая модель ввода-вывода процесса (HIPO)

Модель HIPO (иерархическая модель ввода процесса вывода) — это системного анализа средство проектирования и документирования 1970-х годов. ^[35] используется для представления модулей системы в виде иерархии и для документирования каждого модуля. ^[36]^[37]

Язык моделирования жизненного цикла (LML)

Язык моделирования жизненного цикла (LML) — это язык моделирования с открытым стандартом, предназначенный для системного проектирования . Он поддерживает полный жизненный цикл : этапы разработки, использования, поддержки и вывода из эксплуатации. Наряду с интеграцией всех дисциплин жизненного цикла, включая управление программами , системное и проектирование , верификацию и валидацию , развертывание и обслуживание, в одну структуру. ^[38]LML изначально был разработан руководящим комитетом LML. Спецификация была опубликована 17 октября 2013 года.

Это язык моделирования, такой как UML и SysML , который поддерживает дополнительные возможности управления проектами, такие как анализ рисков и планирование. LML использует общий язык для определения элементов моделирования, таких как сущность, атрибут, график, стоимость и взаимосвязь. ^[39]

Предметно-ориентированное управление бизнес-процессами

Субъектно-ориентированное управление бизнес-процессами (S-BPM) — это взгляд на участников (субъектов), основанный на коммуникации, которые составляют оркестровку или хореографию бизнес-процессов. ^[40] Парадигма моделирования использует пять символов для моделирования любого процесса и позволяет осуществлять прямое преобразование в исполняемую форму.

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

В 2011 и 2012 годах S-BPM был включен в Hype Cycle компании Gartner .

Улучшение когнитивных функций. Метод анализа информации на естественном языке.

Метод анализа информации на естественном языке с улучшением когнитивных функций (CogNIAM) — это концептуальный метод моделирования, основанный на фактах , целью которого является интеграция различных измерений знаний: данных, правил, процессов и семантики. Для представления этих измерений мировые стандарты SBVR , BPMN и DMN от Object Management Group используются (OMG). CogNIAM, преемник NIAM , основан на работах ученого-знатока Сжира Нейссена . ^{[ нужна ссылка ]}

CogNIAM структурирует знания, полученные от людей, документации и программного обеспечения, путем их классификации. Для этой цели CogNIAM использует так называемый «Треугольник знаний». ^[41] Результат CogNIAM не зависит от того, кто его применяет. Полученная модель позволяет выражать знания в схематической форме , а также на контролируемом естественном языке . ^[42]

SIPOC (поставщики, ресурсы, процессы, результаты и клиенты)

При совершенствовании процессов SIPOC или поставщики, входы, процесс, результаты и клиенты (иногда в обратном порядке: COPIS) — это инструмент, который суммирует входные и выходные данные одного или нескольких бизнес-процессов в форме таблицы , где каждое из слов образует столбец таблицы, используемый в анализе. ^[43]^[44] Он используется для определения бизнес-процесса от начала до конца до начала работы по улучшению процесса. ^{[ нужна ссылка ]}

Унифицированный язык моделирования (UML)

Унифицированный язык моделирования общего назначения (UML) — это язык визуального моделирования , предназначенный для обеспечения стандартного способа визуализации проекта системы. ^[45]

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

Создание UML изначально было мотивировано желанием стандартизировать разрозненные системы обозначений и подходы к разработке программного обеспечения. Он был разработан в Rational Software в 1994–1995 годах, а дальнейшая разработка проводилась под их руководством до 1996 года. ^[46]

В 1997 году UML был принят в качестве стандарта Группой управления объектами (OMG) и с тех пор находится под управлением этой организации. В 2005 году UML был также опубликован Международной организацией по стандартизации (ISO) и Международной электротехнической комиссией (IEC) как стандарт ISO/IEC 19501. ^[47] С тех пор стандарт периодически пересматривался, чтобы охватить последнюю версию UML. ^[48]

В разработке программного обеспечения большинство специалистов не используют UML, а вместо этого создают неформальные диаграммы, нарисованные от руки; однако эти диаграммы часто включают элементы UML. ^[49]^: 536

Определение интеграции (IDEF)

IDEF , первоначально аббревиатура ICAM Definition и переименованная в 1999 году в Integration Definition, представляет собой семейство языков моделирования в области системной и программной инженерии. Они охватывают широкий спектр применений: от функционального моделирования до моделирования данных, объектно-ориентированного анализа и проектирования , а также приобретения знаний. Эти языки определений были разработаны при финансовой поддержке ВВС США и, хотя они до сих пор наиболее часто используются ими и другими военными и агентствами Министерства обороны США (DoD), находятся в свободном доступе.

Наиболее широко признанными и используемыми компонентами семейства IDEF являются IDEF0, язык функционального моделирования, основанный на SADT, и IDEF1X, который решает проблемы информационных моделей и проектирования баз данных.

Формализованная административная нотация (ФАН)

Формализованная административная нотация (FAN) — это метод, который позволяет администраторам различных организаций описывать поток и последовательность операций, определять свои обязанности, определять и интегрировать свои транзакции и т. д. Его цель — сформулировать способ внедрения конкретной системы для того, чтобы имеют дальнейшую систематизацию. Первоначально назывался по-испански MECAF ( Metodo de expresion de Circuitos Administrativos Formalizado ).

Моделирование процессов по Харбариану (HPM)

Моделирование процессов по Харбариану (HPM) — это метод получения информации о внутренних процессах организации и последующего документирования этой информации в визуально эффективной и простой форме.

Метод HPM включает в себя два уровня:

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

Язык выполнения бизнес-процессов (BPEL)

Язык выполнения бизнес-процессов веб-сервисов (WS-BPEL), широко известный как BPEL ( язык выполнения бизнес-процессов ), является языком OASIS. ^[50] стандартный исполняемый язык для определения действий внутри бизнес-процессов с веб-сервисами . Процессы в BPEL экспортируют и импортируют информацию, используя исключительно интерфейсы веб-сервисов.

Инструменты

Инструменты моделирования бизнес-процессов предоставляют бизнес-пользователям возможность моделировать свои бизнес-процессы, внедрять и выполнять эти модели, а также уточнять модели на основе фактических данных. В результате инструменты моделирования бизнес-процессов могут обеспечить прозрачность бизнес-процессов, а также централизацию корпоративных моделей бизнес-процессов и показателей выполнения. ^[51] Инструменты моделирования также могут обеспечить совместное моделирование сложных процессов пользователями, работающими в группах, где пользователи могут совместно использовать модели и моделировать их. ^[52] Инструменты моделирования бизнес-процессов не следует путать с системами автоматизации бизнес-процессов — в обеих практиках моделирование процесса является одним и тем же начальным шагом, и разница в том, что автоматизация процесса дает вам «исполняемую диаграмму», которая радикально отличается от традиционного графического моделирования бизнес-процессов. инструменты. ^{[ нужна ссылка ]}

Инструменты языка программирования

Программное обеспечение пакета BPM предоставляет интерфейсы программирования (веб-сервисы, интерфейсы прикладных программ (API)), которые позволяют создавать корпоративные приложения с использованием механизма BPM. ^[51] Этот компонент часто называют движком пакета BPM.

Языки программирования, которые вводятся для BPM, включают: ^[53]

Некоторые языки, специфичные для конкретного поставщика:

Архитектура интегрированных информационных систем (ARIS) поддерживает EPC,
Язык определения процессов Java ( JBPM ),

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

Моделирование

Функциональность моделирования таких инструментов позволяет предварительно выполнить моделирование «что, если» (которое предъявляет особые требования для этого приложения) и симуляцию. Оптимизация после выполнения доступна на основе анализа фактических показателей выполнения. ^[51]

Диаграммы вариантов использования, созданные Иваром Джейкобсоном, 1992 г. (интегрированы в UML)
Диаграммы деятельности (также принятые UML)

Связанные понятия

Эталонная бизнес-модель

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

Наиболее известной эталонной моделью бизнеса является Эталонная бизнес-модель федерального правительства США. Эта модель представляет собой функциональную структуру для описания бизнес-операций федерального правительства, независимых от агентств, которые их выполняют. Справочная бизнес-модель представляет собой организованную иерархическую конструкцию для описания повседневной деловой деятельности федерального правительства. Хотя существует множество моделей для описания организаций – организационные схемы , карты местоположения и т. д. – эта модель представляет бизнес с использованием функционально-ориентированного подхода. ^[55]

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

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

Обычно бизнес-модель создается после проведения собеседования, которое является частью процесса бизнес-анализа . Собеседование состоит из того, что ведущий задает ряд вопросов для получения информации о рассматриваемом бизнес-процессе. Интервьюера называют координатором, чтобы подчеркнуть, что информацию о бизнес-процессе предоставляют участники, а не координатор. Хотя фасилитатор должен обладать некоторыми знаниями о предметном бизнес-процессе, но это не так важно, как владение прагматичным и строгим методом интервьюирования бизнес-экспертов. Этот метод важен, поскольку для большинства предприятий необходима группа координаторов для сбора информации по всему предприятию, а результаты всех интервьюеров должны быть скомпилированы и интегрированы после завершения. ^[56]

Бизнес-модели разрабатываются как определяющие либо текущее состояние процесса (в этом случае конечный продукт называется моделью моментального снимка «как есть»), либо концепцию того, каким должен стать процесс, в результате чего получается модель «как должно быть». Сравнивая и противопоставляя модели «как есть» и «как должно быть», бизнес-аналитики могут определить, являются ли существующие бизнес-процессы и информационные системы надежными и нуждаются лишь в незначительных модификациях, или же для устранения проблем или повышения эффективности требуется реинжиниринг. Следовательно, моделирование бизнес-процессов и последующий анализ могут быть использованы для фундаментального изменения способа ведения деятельности предприятия. ^[56]

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

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

Реинжиниринг бизнес-процессов (BPR) зародился как метод частного сектора, призванный помочь организациям фундаментально переосмыслить то, как они выполняют свою работу. Ключевым стимулом для реинжиниринга стала разработка и внедрение сложных информационных систем и сетей. Ведущие организации используют эту технологию для поддержки инновационных бизнес-процессов, а не для совершенствования существующих способов выполнения работы. ^[57]

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

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

Адаптация моделей процессов

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

См. также

Ссылки

^ Jump up to: ^а ^б ^с ^д Ассоциация специалистов по управлению бизнес-процессами ABPMP (издатель): Руководство по общему массиву знаний по управлению бизнес-процессами - BPM CBOK® в переведенном и отредактированном немецком издании → Европейская ассоциация управления бизнес-процессами EABPM (издатель): Общий орган по управлению бизнес-процессами знаний - BPM CBOK® , 2-я версия, Verlag Dr. Götz Schmidt, Gießen 2009, ISBN 978-3-921313-80-0
^ Jump up to: ^а ^б ^с ^д ^и ^ж ^г ^час ^я Герман Й. Шмельцер и Вольфганг Сессельманн: Управление бизнес-процессами на практике , 9-е издание, Hanser, Мюнхен, 2020 г., ISBN 978-3-446-44625-0
^ Jump up to: ^а ^б ^с ^д ^и ^ж ^г ^час Андреас Гадач: Управление бизнес-процессами / методами и инструментами для ИТ-практики: введение для студентов и практиков , 2-е исправленное и расширенное издание, Vieweg, Брауншвейг/Висбаден, 2002 г., ISBN 978-3-528-15759-3
^ Jump up to: ^а ^б ^с ^д ^и ^ж ^г ^час ^я ^дж ^к Михаэль Роземанн, Ансгар Швегманн и Патрик Дельфманн: Подготовка моделирования процессов в Йорге Беккере, Мартине Куглере и Михаэле Роземамме (издатель): Управление процессами: Руководство по процессно-ориентированному организационному проектированию , 2-е исправленное и расширенное издание, Springer, Берлин/Гейдельберг/ Нью-Йорк, 2002 г., ISBN 978-3-540-00107-2.
^ База знаний: Создайте карту процесса за 6 простых шагов , DER PROZESSMANAGER GmbH (последний доступ: 25 января 2024 г.)
^ Йорг Беккер и Дитер Кан: Процесс в центре внимания Йорга Беккера, Мартина Куглера и Михаэля Роземамма (издатель): Управление процессами: Руководство по процессно-ориентированному организационному проектированию , 2-е исправленное и расширенное издание, Springer, Берлин/Гейдельберг/Нью-Йорк 2002, ISBN 3-540-00107-7
^ Jump up to: ^а ^б ^с ^д ^и ^ж ^г Йорг Беккер и Фолькер Мейзе: Стратегия и организационная структура в книге Йорга Беккера, Мартина Куглера и Михаэля Роземамма (издатель): Управление процессами: Руководство по процессно-ориентированному организационному проектированию , 2-е исправленное и расширенное издание, Springer, Берлин/Гейдельберг/Нью-Йорк, 2002 г. , ISBN 3-540-00107-7
^ Jump up to: ^а ^б Марио Спек и Норберт Шнетгоке: Целевое моделирование и оптимизация процессов в книге Йорга Беккера, Мартина Куглера и Михаэля Роземамма (издатель): Управление процессами: Руководство по процессно-ориентированному организационному проектированию , 2-е исправленное и расширенное издание, Springer, Берлин/Гейдельберг/Нью-Йорк 2002, ISBN 3-540-00107-7
^ Томас Дюфрен и Джеймс Мартин (2003). «Моделирование процессов электронного бизнеса» . INFS 770 Методы проектирования информационных систем: управление знаниями и электронный бизнес. Весна 2003 г. ^{[ мертвая ссылка ]}
^ Уильямс, С. (1967) «Моделирование бизнес-процессов улучшает административный контроль», В: Автоматизация . Декабрь 1967 г., стр. 44–50.
^ Jump up to: ^а ^б Асбьёрн Ролстадас (1995). «Моделирование и реинжиниринг бизнес-процессов». в: Управление производительностью: подход к сравнительному анализу бизнес-процессов . п. 148-150.
^ Брайан К. Уорбойс (1994). Технология обработки программного обеспечения: Третий европейский семинар EWSPT'94 , Виллар де Ланс, Франция, 7–9 февраля 1994 г.: Материалы. п. 252.
^ Джон Мильтенбург, Дэвид Спарлинг: Управление и сокращение общего времени цикла: модели и анализ в Международном журнале экономики производства Elsevier , декабрь 1996 г., страницы 89-108
^ Майкл Молтер: Ландшафт процессно-ориентированных приложений в августе-З. Шеер, Вольфрам Йост и Карл Вагнер (издатель): От моделей процессов к исполняемым приложениям , Springer Berlin, Гейдельберг, Нью-Йорк, 2005 г., ISBN 3-540-23457-8
^ Н. Венкат Венкатраман: Реконфигурация бизнеса, вызванная ИТ, в MS Скотт Мортон (издатель): Корпорация 1990-х годов: информационные технологии и организационная трансформация , 1-е издание, Oxford University Press 1991, ISBN 978-0-19-506358-5
^ Томас Х. Давенпорт : Инновации в процессах: реинжиниринг с помощью информационных технологий , Harvard Business Press, Бостон, 1993, ISBN 978-0-87584-366-7
^ Майкл М. Хаммер , Джеймс А. Чампи : Реинжиниринг корпорации: Манифест бизнес-революции , Harper Business, Нью-Йорк, 1993, ISBN 978-0-88730-640-2
^ Jump up to: ^а ^б ISO 9001:2015: Системы менеджмента качества. Требования , пятое издание, 2015-09 гг., ISO, Международная организация по стандартизации , 2015 г.
^ ISO 14001:2015: Системы экологического менеджмента. Требования и руководство по использованию , Третье издание 2015–09, ISO, Международная организация по стандартизации, 2015.
^ ISO 27001:2022: Информационная безопасность, кибербезопасность и защита конфиденциальности. Системы управления информационной безопасностью. Требования , третье издание 2022–10, ISO, Международная организация по стандартизации 2022.
^ Мартин Куглер: Управление цепочками поставок и управление взаимоотношениями с клиентами - Моделирование процессов для расширенных предприятий в Йорге Беккере, Мартине Куглере и Майкле Роземамме (издатель): Управление процессами: Руководство по процессно-ориентированному организационному проектированию , 2-е исправленное и расширенное издание, Springer, Берлин/Гейдельберг/Нью-Йорк 2002, ISBN 3-540-00107-7
^ Jump up to: ^а ^б Тимо Фюрманн: Управление процессами: компактные знания, конкретная реализация, практические пособия , Hanser, Мюнхен, 2014 г., ISBN 978-3-446-43858-3
^ Jump up to: ^а ^б ^с ^д Ансгар Швегманн и Михаэль Ласке: Актуальное моделирование и фактический анализ в книге Йорга Беккера, Мартина Куглера и Михаэля Роземамма (издатель): Управление процессами: Руководство по процессно-ориентированному организационному проектированию , 2-е исправленное и расширенное издание, Springer, Берлин/Гейдельберг/Нью-Йорк 2002, ISBN 3-540-00107-7
^ «ИСО – Международная организация по стандартизации» . ИСО . 27 мая 2024 г.
^ Август-В. Шеер: АРИС: От видения к практическому управлению бизнес-процессами в августе-З. Шеер и Вольфрам Йост (ред.): ARIS на практике: проектирование, внедрение и оптимизация бизнес-процессов , Springer, Берлин/Гейдельберг/Нью-Йорк, 2002 г., ISBN 3-540-43029-6.
^ Ёнчареон, Сира (2015). «Структура представления для моделирования и проверки изменений межорганизационных бизнес-процессов, ориентированных на артефакты». Информационные системы . 47 : 51–81. дои : 10.1016/j.is.2014.07.004 .
^ Седрик Г. Тайлер и Стивен Р. Бейкер: Генетика бизнеса: понимание корпораций 21-го века, использующих xBML , John Wiley & Sons Ltd, 2007, ISBN 978-0-470-06654-6
^ «Архивная копия» . Архивировано из оригинала 9 января 2014 г. Проверено 19 февраля 2024 г. {{cite web}}: CS1 maint: архивная копия в качестве заголовка ( ссылка ) CS1 maint: bot: исходный статус URL неизвестен ( ссылка ), доступ осуществлен 19 февраля 2024 г.
^ Архивировано (дата отсутствует) на prof-mayr.de (ошибка: неизвестный URL-адрес архива) , на prof-mayr.de, получено 5 февраля 2024 г.; PDF «VL4030_OMEGA+ метод описания.pdf» больше не доступен.
^ МОЙ БОГ. «БПМН 2.0» . Проверено 29 марта 2011 г.
^ «О модели бизнес-процессов и спецификации нотаций версии 2.0.2» . www.omg.org . Проверено 7 декабря 2020 г.
^ <trans oldtip="А.-В.Шеер (2002). " newtip="А.-В.Шеер(2002年)。">А.-В.Шеер(2002年)。</trans> <trans oldtip="ARIS. От бизнес-процесса к системе приложений" newtip="阿里斯。бизнес-процесс виртуальной машины к системе приложений">阿里斯。бизнес-процесс виртуальной машины к системе приложений</trans> . Спрингер. стр.20.
^ Петри, Карл Адам; Райзиг, Вольфганг (2008). «Сеть Петри» . Схоларпедия . 3 (4): 6477. Бибкод : 2008SchpJ...3.6477P . doi : 10.4249/scholarpedia.6477 .
^ SEVOCAB: Словарь по проектированию программных систем . Термин: Блок-схема . Проверено 31 июля 2008 г.
^ Корпорация IBM (1974). HIPO — средство проектирования и документирования , номер публикации GC20-1851, IBM Corporation, Уайт-Плейнс, Нью-Йорк, 1974.
^ Кацан, Гарри младший (1976). Системное проектирование и документация: введение в метод HIPO . Ван Ностранд Рейнхольд. ISBN 0-442-24267-0 .
^ Национальные лаборатории Сандии (1992). Руководство по программному обеспечению Sandia, том 5, инструменты, методы и методологии. Архивировано 25 августа 2009 г. в Wayback Machine. ОТЧЕТЫ SANDIA 85–2348qUC–32.
^ Руководящий комитет LML. «Спецификация LML» . Проверено 01 марта 2023 г.
^ «О языке моделирования жизненного цикла» . Руководящий комитет LML . Проверено 5 июня 2014 г.
^ Флейшманн, Альберт; Старый, Кристиан (2011). «С кем поговорить? Взгляд заинтересованных сторон на развитие бизнес-процессов» . Универсальный доступ в информационном обществе . 11 (2): 1–28. дои : 10.1007/s10209-011-0236-x .
^ Сьер Нейссен и Андре Ле Кэт. Работа, основанная на знаниях], 2009. с. 118-148
^ Нейссен, Герардус Мария и Теренс Эйдан Хэлпин . Концептуальная схема и проектирование реляционной базы данных: подход, ориентированный на факты. Прентис-Холл, Инк., 1989.
^ Саймон, Керри (26 февраля 2010 г.). «Диаграмма SIPOC» . Риджфилд, Коннектикут : iSixSigma . Проверено 3 июля 2012 г.
^ «Диаграмма SIPOC (поставщики, входы, процесс, выходы, клиенты)» . Милуоки, Висконсин : Американское общество качества . Проверено 29 января 2020 г.
^ Единый язык моделирования 2.5.1 . Официальный номер документа OMG /05.12.2017. Организация по разработке стандартов группы управления объектами (OMG SDO). Декабрь 2017.
^ Руководство пользователя унифицированного языка моделирования, The (2-е изд.). Аддисон-Уэсли. 2005. с. 496. ИСБН 0321267974 . Посмотрите пример содержания: ищите историю
^ «ISO/IEC 19501:2005. Информационные технологии. Открытая распределенная обработка. Унифицированный язык моделирования (UML), версия 1.4.3» . Исо.орг. 01 апреля 2005 г. Проверено 7 мая 2015 г.
^ «ISO/IEC 19505-1:2012. Информационные технологии. Унифицированный язык моделирования группы управления объектами (OMG UML). Часть 1. Инфраструктура» . Исо.орг. 20 апреля 2012 г. Проверено 10 апреля 2014 г.
^ Себастьян Балтес; Стефан Диль (11 ноября 2014 г.). «Эскизы и схемы на практике» . Материалы 22-го Международного симпозиума ACM SIGSOFT по основам программной инженерии . ФСЕ 2014. Ассоциация вычислительной техники . стр. 530–541. arXiv : 1706.09172 . дои : 10.1145/2635868.2635891 . ISBN 978-1-4503-3056-5 . S2CID 2436333 .
^ Стандарт OASIS WS-BPEL 2.0
^ Jump up to: ^а ^б ^с Шаблон службы управления рабочими процессами/бизнес-процессами (BPM). Архивировано 13 января 2009 г. на Wayback Machine 27 июня 2007 г. Доступ осуществлен 29 ноября 2008 г.
^ Кристенсен, Ларс Руне и Томас Хильдебрандт (2017) Моделирование совместной работы на медицинском факультете . Материалы 8-й Международной конференции по сообществам и технологиям. Труа, Франция. АКМ.
^ «Часто задаваемые вопросы по моделированию бизнес-процессов» . Архивировано из оригинала 9 ноября 2008 г. Проверено 2 ноября 2008 г.
^ FEA (2005) Профиль управления записями FEA, версия 1.0 . 15 декабря 2005 г.
^ Документ консолидированной эталонной модели FEA, заархивированный 11 октября 2010 г. в Wayback Machine . Октябрь 2007 г.
^ Jump up to: ^а ^б ^с ^д Пол Р. Смит и Ричард Сарфати (1993). Создание стратегического плана управления конфигурацией с использованием инструментов компьютерной разработки программного обеспечения (CASE). Документ для группы пользователей CAD/CAE Национального Министерства энергетики/подрядчиков и предприятий 1993 года.
↑ Руководство по оценке реинжиниринга бизнес-процессов. Архивировано 18 февраля 2017 г. в Wayback Machine , Главное бухгалтерское управление США, май 1997 г.

Дальнейшее чтение

Агилар-Савен, Рут Сара. « Моделирование бизнес-процессов: обзор и структура. Архивировано 7 августа 2020 г. на Wayback Machine ». Международный журнал экономики производства 90.2 (2004): 129–149.
Барджис, Джозеф (2008). «Важность моделирования бизнес-процессов при проектировании программных систем» . Наука компьютерного программирования . 71 : 73–87. дои : 10.1016/j.scico.2008.01.002 .
Беккер, Йорг, Михаэль Роземанн и Кристоф фон Утманн. « Руководство по моделированию бизнес-процессов ». Управление бизнес-процессами. Springer Berlin Heidelberg, 2000. 30–49.
Хоммес, Л. Дж. Оценка методов моделирования бизнес-процессов . Докторская диссертация. Технический университет Делфта.
Ховард Д. Йоргенсен (2004). Интерактивные модели процессов . Диссертация Норвежского университета науки и технологий, Тронхейм, Норвегия.
Мануэль Лагуна, Йохан Марклунд (2004). Моделирование, симуляция и проектирование бизнес-процессов . Пирсон/Прентис Холл, 2004.
Овидиу С. Норан (2000). Бизнес-моделирование: UML против IDEF Paper Griffh University
Ян Рекер (2005). «Моделирование процессов в XXI веке» . В: BP Trends, май 2005 г.
Райан К.Л. Ко, Стивен С.Г. Ли, Энг Ва Ли (2009) Стандарты управления бизнес-процессами (BPM): обзор . В: Журнал управления бизнес-процессами, Emerald Group Publishing Limited. Том 15 Выпуск 5. ISSN 1463-7154.
Ян Вантиенен , С. Гедертье и Р. Хаесен (2007). «EM-BrA2CE v0.1: словарь и модель выполнения для декларативного моделирования бизнес-процессов» . DTEW - KBI_0728.

Внешние ссылки

СМИ, связанные с моделированием бизнес-процессов, на Викискладе?

[EABPM-1] Jump up to: ^а ^б ^с ^д Ассоциация специалистов по управлению бизнес-процессами ABPMP (издатель): Руководство по общему массиву знаний по управлению бизнес-процессами - BPM CBOK® в переведенном и отредактированном немецком издании → Европейская ассоциация управления бизнес-процессами EABPM (издатель): Общий орган по управлению бизнес-процессами знаний - BPM CBOK® , 2-я версия, Verlag Dr. Götz Schmidt, Gießen 2009, ISBN 978-3-921313-80-0

[SCHMELZER-2] Jump up to: ^а ^б ^с ^д ^и ^ж ^г ^час ^я Герман Й. Шмельцер и Вольфганг Сессельманн: Управление бизнес-процессами на практике , 9-е издание, Hanser, Мюнхен, 2020 г., ISBN 978-3-446-44625-0

[GADATSCH-3] Jump up to: ^а ^б ^с ^д ^и ^ж ^г ^час Андреас Гадач: Управление бизнес-процессами / методами и инструментами для ИТ-практики: введение для студентов и практиков , 2-е исправленное и расширенное издание, Vieweg, Брауншвейг/Висбаден, 2002 г., ISBN 978-3-528-15759-3

[ROSEMANN-4] Jump up to: ^а ^б ^с ^д ^и ^ж ^г ^час ^я ^дж ^к Михаэль Роземанн, Ансгар Швегманн и Патрик Дельфманн: Подготовка моделирования процессов в Йорге Беккере, Мартине Куглере и Михаэле Роземамме (издатель): Управление процессами: Руководство по процессно-ориентированному организационному проектированию , 2-е исправленное и расширенное издание, Springer, Берлин/Гейдельберг/ Нью-Йорк, 2002 г., ISBN 978-3-540-00107-2.

[5] База знаний: Создайте карту процесса за 6 простых шагов , DER PROZESSMANAGER GmbH (последний доступ: 25 января 2024 г.)

[BECKER-KAHN-6] Йорг Беккер и Дитер Кан: Процесс в центре внимания Йорга Беккера, Мартина Куглера и Михаэля Роземамма (издатель): Управление процессами: Руководство по процессно-ориентированному организационному проектированию , 2-е исправленное и расширенное издание, Springer, Берлин/Гейдельберг/Нью-Йорк 2002, ISBN 3-540-00107-7

[BECKER-MEISE-7] Jump up to: ^а ^б ^с ^д ^и ^ж ^г Йорг Беккер и Фолькер Мейзе: Стратегия и организационная структура в книге Йорга Беккера, Мартина Куглера и Михаэля Роземамма (издатель): Управление процессами: Руководство по процессно-ориентированному организационному проектированию , 2-е исправленное и расширенное издание, Springer, Берлин/Гейдельберг/Нью-Йорк, 2002 г. , ISBN 3-540-00107-7

[SPECK-SCHNETT-8] Jump up to: ^а ^б Марио Спек и Норберт Шнетгоке: Целевое моделирование и оптимизация процессов в книге Йорга Беккера, Мартина Куглера и Михаэля Роземамма (издатель): Управление процессами: Руководство по процессно-ориентированному организационному проектированию , 2-е исправленное и расширенное издание, Springer, Берлин/Гейдельберг/Нью-Йорк 2002, ISBN 3-540-00107-7

[TD03-9] Томас Дюфрен и Джеймс Мартин (2003). «Моделирование процессов электронного бизнеса» . INFS 770 Методы проектирования информационных систем: управление знаниями и электронный бизнес. Весна 2003 г. ^{[ мертвая ссылка ]}

[10] Уильямс, С. (1967) «Моделирование бизнес-процессов улучшает административный контроль», В: Автоматизация . Декабрь 1967 г., стр. 44–50.

[Rol95-11] Jump up to: ^а ^б Асбьёрн Ролстадас (1995). «Моделирование и реинжиниринг бизнес-процессов». в: Управление производительностью: подход к сравнительному анализу бизнес-процессов . п. 148-150.

[12] Брайан К. Уорбойс (1994). Технология обработки программного обеспечения: Третий европейский семинар EWSPT'94 , Виллар де Ланс, Франция, 7–9 февраля 1994 г.: Материалы. п. 252.

[MILTENBURG-SPARLING-13] Джон Мильтенбург, Дэвид Спарлинг: Управление и сокращение общего времени цикла: модели и анализ в Международном журнале экономики производства Elsevier , декабрь 1996 г., страницы 89-108

[MOLTER-14] Майкл Молтер: Ландшафт процессно-ориентированных приложений в августе-З. Шеер, Вольфрам Йост и Карл Вагнер (издатель): От моделей процессов к исполняемым приложениям , Springer Berlin, Гейдельберг, Нью-Йорк, 2005 г., ISBN 3-540-23457-8

[15] Н. Венкат Венкатраман: Реконфигурация бизнеса, вызванная ИТ, в MS Скотт Мортон (издатель): Корпорация 1990-х годов: информационные технологии и организационная трансформация , 1-е издание, Oxford University Press 1991, ISBN 978-0-19-506358-5

[DAVENPORT-16] Томас Х. Давенпорт : Инновации в процессах: реинжиниринг с помощью информационных технологий , Harvard Business Press, Бостон, 1993, ISBN 978-0-87584-366-7

[HAMMER-CHAMPY-17] Майкл М. Хаммер , Джеймс А. Чампи : Реинжиниринг корпорации: Манифест бизнес-революции , Harper Business, Нью-Йорк, 1993, ISBN 978-0-88730-640-2

[ISO-9001-18] Jump up to: ^а ^б ISO 9001:2015: Системы менеджмента качества. Требования , пятое издание, 2015-09 гг., ISO, Международная организация по стандартизации , 2015 г.

[19] ISO 14001:2015: Системы экологического менеджмента. Требования и руководство по использованию , Третье издание 2015–09, ISO, Международная организация по стандартизации, 2015.

[20] ISO 27001:2022: Информационная безопасность, кибербезопасность и защита конфиденциальности. Системы управления информационной безопасностью. Требования , третье издание 2022–10, ISO, Международная организация по стандартизации 2022.

[KUGLER-21] Мартин Куглер: Управление цепочками поставок и управление взаимоотношениями с клиентами - Моделирование процессов для расширенных предприятий в Йорге Беккере, Мартине Куглере и Майкле Роземамме (издатель): Управление процессами: Руководство по процессно-ориентированному организационному проектированию , 2-е исправленное и расширенное издание, Springer, Берлин/Гейдельберг/Нью-Йорк 2002, ISBN 3-540-00107-7

[FUEERMANN-22] Jump up to: ^а ^б Тимо Фюрманн: Управление процессами: компактные знания, конкретная реализация, практические пособия , Hanser, Мюнхен, 2014 г., ISBN 978-3-446-43858-3

[SCHWEGMANN-LASKE-23] Jump up to: ^а ^б ^с ^д Ансгар Швегманн и Михаэль Ласке: Актуальное моделирование и фактический анализ в книге Йорга Беккера, Мартина Куглера и Михаэля Роземамма (издатель): Управление процессами: Руководство по процессно-ориентированному организационному проектированию , 2-е исправленное и расширенное издание, Springer, Берлин/Гейдельберг/Нью-Йорк 2002, ISBN 3-540-00107-7

[24] «ИСО – Международная организация по стандартизации» . ИСО . 27 мая 2024 г.

[SCHEER-25] Август-В. Шеер: АРИС: От видения к практическому управлению бизнес-процессами в августе-З. Шеер и Вольфрам Йост (ред.): ARIS на практике: проектирование, внедрение и оптимизация бизнес-процессов , Springer, Берлин/Гейдельберг/Нью-Йорк, 2002 г., ISBN 3-540-43029-6.

[26] Ёнчареон, Сира (2015). «Структура представления для моделирования и проверки изменений межорганизационных бизнес-процессов, ориентированных на артефакты». Информационные системы . 47 : 51–81. дои : 10.1016/j.is.2014.07.004 .

[27] Седрик Г. Тайлер и Стивен Р. Бейкер: Генетика бизнеса: понимание корпораций 21-го века, использующих xBML , John Wiley & Sons Ltd, 2007, ISBN 978-0-470-06654-6

[28] «Архивная копия» . Архивировано из оригинала 9 января 2014 г. Проверено 19 февраля 2024 г. {{cite web}}: CS1 maint: архивная копия в качестве заголовка ( ссылка ) CS1 maint: bot: исходный статус URL неизвестен ( ссылка ), доступ осуществлен 19 февраля 2024 г.

[29] Архивировано (дата отсутствует) на prof-mayr.de (ошибка: неизвестный URL-адрес архива) , на prof-mayr.de, получено 5 февраля 2024 г.; PDF «VL4030_OMEGA+ метод описания.pdf» больше не доступен.

[Business_Process_Model_and_Notation_BPMN20-30] МОЙ БОГ. «БПМН 2.0» . Проверено 29 марта 2011 г.

[31] «О модели бизнес-процессов и спецификации нотаций версии 2.0.2» . www.omg.org . Проверено 7 декабря 2020 г.

[32] <trans oldtip="А.-В.Шеер (2002). " newtip="А.-В.Шеер(2002年)。">А.-В.Шеер(2002年)。</trans> <trans oldtip="ARIS. От бизнес-процесса к системе приложений" newtip="阿里斯。бизнес-процесс виртуальной машины к системе приложений">阿里斯。бизнес-процесс виртуальной машины к системе приложений</trans> . Спрингер. стр.20.

[33] Петри, Карл Адам; Райзиг, Вольфганг (2008). «Сеть Петри» . Схоларпедия . 3 (4): 6477. Бибкод : 2008SchpJ...3.6477P . doi : 10.4249/scholarpedia.6477 .

[Flowchart_SSEV-34] SEVOCAB: Словарь по проектированию программных систем . Термин: Блок-схема . Проверено 31 июля 2008 г.

[35] Корпорация IBM (1974). HIPO — средство проектирования и документирования , номер публикации GC20-1851, IBM Corporation, Уайт-Плейнс, Нью-Йорк, 1974.

[36] Кацан, Гарри младший (1976). Системное проектирование и документация: введение в метод HIPO . Ван Ностранд Рейнхольд. ISBN 0-442-24267-0 .

[HIPO_model_Sandia92-37] Национальные лаборатории Сандии (1992). Руководство по программному обеспечению Sandia, том 5, инструменты, методы и методологии. Архивировано 25 августа 2009 г. в Wayback Machine. ОТЧЕТЫ SANDIA 85–2348qUC–32.

[Lifecycle_Modeling_Language_specification-38] Руководящий комитет LML. «Спецификация LML» . Проверено 01 марта 2023 г.

[39] «О языке моделирования жизненного цикла» . Руководящий комитет LML . Проверено 5 июня 2014 г.

[Subject-oriented_business_process_management_Fleischmann.2011-40] Флейшманн, Альберт; Старый, Кристиан (2011). «С кем поговорить? Взгляд заинтересованных сторон на развитие бизнес-процессов» . Универсальный доступ в информационном обществе . 11 (2): 1–28. дои : 10.1007/s10209-011-0236-x .

[41] Сьер Нейссен и Андре Ле Кэт. Работа, основанная на знаниях], 2009. с. 118-148

[42] Нейссен, Герардус Мария и Теренс Эйдан Хэлпин . Концептуальная схема и проектирование реляционной базы данных: подход, ориентированный на факты. Прентис-Холл, Инк., 1989.

[43] Саймон, Керри (26 февраля 2010 г.). «Диаграмма SIPOC» . Риджфилд, Коннектикут : iSixSigma . Проверено 3 июля 2012 г.

[44] «Диаграмма SIPOC (поставщики, входы, процесс, выходы, клиенты)» . Милуоки, Висконсин : Американское общество качества . Проверено 29 января 2020 г.

[Unified_Modeling_Language_OMG-45] Единый язык моделирования 2.5.1 . Официальный номер документа OMG /05.12.2017. Организация по разработке стандартов группы управления объектами (OMG SDO). Декабрь 2017.

[Unified_Modeling_Language_:1-46] Руководство пользователя унифицированного языка моделирования, The (2-е изд.). Аддисон-Уэсли. 2005. с. 496. ИСБН 0321267974 . Посмотрите пример содержания: ищите историю

[47] «ISO/IEC 19501:2005. Информационные технологии. Открытая распределенная обработка. Унифицированный язык моделирования (UML), версия 1.4.3» . Исо.орг. 01 апреля 2005 г. Проверено 7 мая 2015 г.

[48] «ISO/IEC 19505-1:2012. Информационные технологии. Унифицированный язык моделирования группы управления объектами (OMG UML). Часть 1. Инфраструктура» . Исо.орг. 20 апреля 2012 г. Проверено 10 апреля 2014 г.

[49] Себастьян Балтес; Стефан Диль (11 ноября 2014 г.). «Эскизы и схемы на практике» . Материалы 22-го Международного симпозиума ACM SIGSOFT по основам программной инженерии . ФСЕ 2014. Ассоциация вычислительной техники . стр. 530–541. arXiv : 1706.09172 . дои : 10.1145/2635868.2635891 . ISBN 978-1-4503-3056-5 . S2CID 2436333 .

[50] Стандарт OASIS WS-BPEL 2.0

[NIH07-51] Jump up to: ^а ^б ^с Шаблон службы управления рабочими процессами/бизнес-процессами (BPM). Архивировано 13 января 2009 г. на Wayback Machine 27 июня 2007 г. Доступ осуществлен 29 ноября 2008 г.

[52] Кристенсен, Ларс Руне и Томас Хильдебрандт (2017) Моделирование совместной работы на медицинском факультете . Материалы 8-й Международной конференции по сообществам и технологиям. Труа, Франция. АКМ.

[bpmfaq-53] «Часто задаваемые вопросы по моделированию бизнес-процессов» . Архивировано из оригинала 9 ноября 2008 г. Проверено 2 ноября 2008 г.

[54] FEA (2005) Профиль управления записями FEA, версия 1.0 . 15 декабря 2005 г.

[55] Документ консолидированной эталонной модели FEA, заархивированный 11 октября 2010 г. в Wayback Machine . Октябрь 2007 г.

[SS93-56] Jump up to: ^а ^б ^с ^д Пол Р. Смит и Ричард Сарфати (1993). Создание стратегического плана управления конфигурацией с использованием инструментов компьютерной разработки программного обеспечения (CASE). Документ для группы пользователей CAD/CAE Национального Министерства энергетики/подрядчиков и предприятий 1993 года.

[GAO97-57] Руководство по оценке реинжиниринга бизнес-процессов. Архивировано 18 февраля 2017 г. в Wayback Machine , Главное бухгалтерское управление США, май 1997 г.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

[29]

[30]

[31]

[32]

[33]

[34]

[35]

[36]

[37]

[38]

[39]

[40]

[41]

[42]

[43]

[44]

[45]

[46]

[47]

[48]

[49]

[50]

[51]

[52]

[53]

[54]

[55]

[56]

[57]

v т и Системная инженерия
Subfields	Aerospace engineering Biological systems engineering Cognitive systems engineering Configuration management Earth systems engineering and management Electrical engineering Enterprise systems engineering Health systems engineering Performance engineering Reliability engineering Safety engineering Sociocultural Systems Engineering
Processes	Requirements engineering Functional specification System integration Verification and validation Design review System of systems engineering
Concepts	Business process Fault tolerance System System lifecycle V-Model Systems development life cycle
Tools	Decision-making Function modelling IDEF Optimization Quality function deployment System dynamics Systems Modeling Language Systems analysis Systems modeling Work breakdown structure
People	James S. Albus Ruzena Bajcsy Benjamin S. Blanchard Wernher von Braun Kathleen Carley Harold Chestnut Wolt Fabrycky Barbara Grosz Arthur David Hall III Derek Hitchins Robert E. Machol Radhika Nagpal Simon Ramo Joseph Francis Shea Katia Sycara Manuela M. Veloso John N. Warfield
Related fields	Control engineering Computer engineering Industrial engineering Operations research Project management Quality management Risk management Software engineering
Category