Моделирование бизнес-процессов ( 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 Управление процессами) ← автоматический перевод с немецкого
Моделирование бизнес-процессов также является центральным аспектом комплексного картирования компании, которое также занимается картированием корпоративной миссии , корпоративной политики/ корпоративного управления , организационной структуры, организации процессов, архитектуры приложений , правил и групп интересов, а также рынка .
.gif/1280px-Core_process_(quality_management).gif)
По данным Европейской ассоциации управления бизнес-процессами (EABPM), «существует три различных типа сквозных бизнес-процессов:
Эти три типа процессов можно определить в каждой компании, и они используются на практике почти без исключений в качестве верхнего уровня для структурирования моделей бизнес-процессов. [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 Характеристики и свойства процессов) ← автоматический перевод с немецкого ):
Поскольку моделирование бизнес-процессов само по себе не вносит прямого вклада в финансовый успех компании, мотивация к моделированию бизнес-процессов не исходит из важнейшей цели компании — намерения получить прибыль . Поэтому мотивация компании заниматься моделированием бизнес-процессов всегда вытекает из соответствующей цели. Михаэль Роземанн, Ансгар Швегманн и Патрик Делфманн перечисляют ряд целей в качестве мотивации к моделированию бизнес-процессов:
В рамках обширной исследовательской программы, начатой в 1984 году под названием «Управление в 1990-х» в Массачусетском технологическом институте , в начале 1990-х годов появился подход к реинжинирингу процессов . Исследовательская программа была разработана для изучения влияния информационных технологий на то, как организации смогут выживать и процветать в конкурентной среде 1990-х годов и далее. В заключительном отчете Н. Венкат Венкатраман [15] резюмирует результат следующим образом: Наибольшего повышения производительности можно достичь, когда новые процессы планируются параллельно с информационными технологиями.
Этот подход был принят Томасом Х. Дэвенпортом [16] (Часть I: Структура для инноваций в процессах, Глава: Введение), а также Майклом М. Хаммером и Джеймсом А. Чампи [17] и развили его в реинжиниринг бизнес-процессов (BPR), как мы его понимаем сегодня, согласно которому бизнес-процессы фундаментально реструктурируются с целью достижения улучшения измеримых показателей эффективности, таких как затраты, качество, обслуживание и время.
Реинжиниринг бизнес-процессов частично критиковался за то, что начинался с «зеленого поля» и, следовательно, не был напрямую реализован для устоявшихся компаний. Герман Й. Шмельцер и Вольфганг Сессельман оценивают это следующим образом: «Критика BPR во многих отношениях носит академический характер. ... Некоторые из высказанных критических замечаний оправданы с практической точки зрения. Это включает указание на то, что чрезмерно радикальный подход несет в себе риск неудачи. Это особенно проблематично, если организация и сотрудники недостаточно подготовлены к BPR». [2] (Глава 6.2.1 Цели и концепция) ← автоматический перевод с немецкого
По мнению Томаса Х. Дэвенпорта, высокоуровневый подход к BPR состоит из:
.svg/1280px-ISO_Logo_(Red_square).svg.png){kind=logo}
С появлением ISO/IEC 27001:2022 стандартные требования к системам менеджмента теперь унифицированы для всех основных стандартов ISO и носят процессный характер.
В стандартах ISO/IEC 9001, ISO/IEC 14001 , ISO/IEC 27001 это закреплено в главе 4.4 в каждом случае:
Каждый из этих стандартов требует от организации создания, внедрения, поддержания и постоянного совершенствования соответствующей системы управления, «включая необходимые процессы и их взаимодействие». [18] , [19] , [20]
В определении стандартных требований к необходимым процессам и их взаимодействию стандарт ISO/IEC 9001 в пункте 4.4.1 более конкретен, чем любой другой стандарт ISO для систем менеджмента, и определяет, что «организация должна определить и применять процессы, необходимые для» [18] соответствующей системы менеджмента во всей организации, а также перечисляет подробные требования в отношении процессов:
Кроме того, в пункте 4.4.2 стандарта ISO/IEC 9001 перечислены некоторые более подробные требования в отношении процессов:
Внедрение стандартных требований к необходимым процессам и их взаимодействиям , в частности, доказательство внедрения стандартных требований с помощью адекватной документации (моделирование бизнес-процессов) является обычной практикой. Это также означает, что стандартные требования к документированной информации также актуальны для моделирования бизнес-процессов как части системы управления ISO.
В стандартах ISO/IEC 9001, ISO/IEC 14001, ISO/IEC 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 должно поддерживать адекватное документирование барьеров, управления барьерами и измерения.
При изучении инструментов Kaizen изначально нет прямой связи с бизнес-процессами или моделированием бизнес-процессов. Однако Kaizen и управление бизнес-процессами могут взаимно усиливать друг друга. В сфере управления бизнес-процессами цели Kaizen напрямую вытекают из целей бизнес-процессов и подпроцессов. Эта связь гарантирует, что меры Kaizen эффективно поддерживают общие бизнес-цели." [2] (Глава 6.3.3 KAIZEN) ← автоматический перевод с немецкого
Six Sigma предназначена для предотвращения ошибок и улучшения возможностей процесса таким образом, чтобы доля результатов процесса, соответствующих требованиям, составляла 6σ — или, другими словами, на каждый миллион результатов процесса приходилось всего 3,4 ошибки. Герман Й. Шмельцер и Вольфганг Сессельманн объясняют: «Компании часто сталкиваются со значительным сопротивлением на уровне 4σ, что делает необходимым перепроектирование бизнес-процессов в смысле реинжиниринга бизнес-процессов (проектирование для Six Sigma)». [2] (Глава 6.3.4 Six Sigma) ← автоматический перевод с немецкого Для воспроизводимого измерения возможностей процесса требуются точные знания бизнес-процессов, и моделирование бизнес-процессов является подходящим инструментом для проектирования для Six Sigma. Поэтому Six Sigma использует моделирование бизнес-процессов в соответствии с SIPOC как неотъемлемую часть методологии, а моделирование бизнес-процессов с использованием SIPOC зарекомендовало себя как стандартный инструмент для Six Sigma.
Целью моделирования межфирменных бизнес-процессов является включение в анализ влияния внешних заинтересованных сторон или достижение межфирменной сопоставимости бизнес-процессов, например, для проведения бенчмаркинга.
Мартин Куглер перечисляет следующие требования к моделированию бизнес-процессов в этом контексте: [21] (Глава 14.2.1 Требования к моделированию межфирменных бизнес-процессов) ← автоматический перевод с немецкого
Анализ деятельности предприятия определяет и определяет рамочные условия для успешного моделирования бизнес-процессов. Это то, с чего компания должна начать,
разработать подход к структурированию моделей бизнес-процессов. Как соответствующие цели , так и стратегия напрямую влияют на карту процесса .
Эта стратегия долгосрочного успеха моделирования бизнес-процессов может быть охарактеризована как рыночно-ориентированный взгляд и/или ресурсно-ориентированный взгляд. Йорг Беккер и Фолькер Мейсе объясняют: «В то время как в рыночном взгляде отрасль и поведение конкурентов напрямую определяют стратегию компании, ресурсно-ориентированный подход принимает внутренний взгляд, анализируя сильные и слабые стороны компании и выводя из этого направление развития стратегии». [7] (Глава 4.6 Ресурсно-ориентированный взгляд) ← автоматический перевод с немецкого И далее: «Альтернативный характер, первоначально сформулированный в литературе между рыночно-ориентированным и ресурсно-ориентированным взглядами, теперь уступил место дифференцированной перспективе. Подход на основе основных компетенций рассматривается как важный вклад в объяснение потенциала успеха, который используется наряду с существующими рыночно-ориентированными подходами». [7] (Глава 4.7 Объединение взглядов) ← автоматический перевод с немецкого В зависимости от стратегии компании карта процесса будет, таким образом, представлять собой модели бизнес-процессов с целью развития рынка, с целью оптимизации ресурсов или сбалансированным образом.
После этапа идентификации бизнес-процессы компании различаются друг от друга посредством анализа их соответствующих бизнес-деятельностей (см. также анализ бизнес-процессов). Бизнес-процесс представляет собой набор взаимосвязанных, организованных действий (мероприятий), направленных на предоставление определенной услуги или продукта (для достижения определенной цели) для определенного клиента или группы клиентов.
По данным Европейской ассоциации управления бизнес-процессами (EABPM), установление общего понимания текущего процесса и его соответствия целям является первым шагом в проектировании или реинжиниринге процесса." [1] (Глава 4 Анализ процесса) ← автоматический перевод с немецкого
Усилия, необходимые для анализа текущих процессов, неоднократно подвергаются критике в литературе, особенно со стороны сторонников реинжиниринга бизнес-процессов (BPR), и предлагается немедленно приступить к определению целевого состояния.
Герман Й. Шмельцер и Вольфганг Сессельманн , с другой стороны, обсуждают и оценивают критику радикального подхода к реинжинирингу бизнес-процессов (BPR) в литературе и «рекомендуют проводить анализы «как есть». Реорганизация должна знать текущие слабые места, чтобы иметь возможность устранить их. Результаты анализов также предоставляют аргументы относительно того, почему реинжиниринг процессов необходим. Также важно знать начальную ситуацию для перехода от текущего к целевому состоянию. Однако усилия по анализу должны быть ограничены узкими рамками. Результаты анализов также не должны слишком сильно влиять на редизайн». [2] (Глава 6.2.2 Критическая оценка BPR) ← автоматический перевод с немецкого
Тимо Фюрманн объясняет: «После того, как бизнес-процессы были идентифицированы и названы, они теперь собираются в обзор. Такие обзоры называются картами процессов». [22] (Глава 2.4 Создание карты процесса) ← автоматический перевод с немецкого
Йорг Беккер и Фолькер Майсе предлагают следующий перечень мероприятий по структурированию бизнес-процессов:
Структурирование бизнес-процессов обычно начинается с разграничения управленческих, основных и вспомогательных процессов.
Поскольку основные бизнес-процессы, очевидно, составляют большую часть идентифицированных бизнес-процессов компании, стало обычной практикой снова подразделять основные процессы. Существуют различные подходы к этому в зависимости от типа компании и вида деятельности. Эти подходы в значительной степени зависят от определенного применения моделирования бизнес-процессов и стратегии долгосрочного успеха моделирования бизнес-процессов .
В случае стратегии, основанной в первую очередь на рынке, сквозные основные бизнес-процессы часто определяются от клиента или поставщика до розничного продавца или клиента (например, «от предложения до заказа», «от заказа до счета-фактуры», «от заказа до доставки», «от идеи до продукта» и т. д.). В случае стратегии, основанной на ресурсах, основные бизнес-процессы часто определяются на основе центральных корпоративных функций («получение заказов», «закупка и предоставление материалов», «разработка продуктов», «предоставление услуг» и т. д.).
При дифференцированном подходе без четкого фокуса на рыночном или ресурсном взгляде основные бизнес-процессы обычно делятся на CRM, PLM и SCM.
Однако распространены и другие подходы к структурированию основных бизнес-процессов, например, с точки зрения клиентов, продуктов или каналов продаж.
Результатом структурирования бизнес-процессов компании является карта процесса (показанная, например, в виде диаграммы цепочки создания стоимости ). Герман Й. Шмельцер и Вольфганг Сессельманн добавляют: «Между бизнес-процессами существуют связи и зависимости. Они основаны на передаче услуг и информации. Важно знать эти взаимосвязи, чтобы понимать, управлять и контролировать бизнес-процессы». [2] (Глава 2.4.3 Карта процесса) ← автоматический перевод с немецкого
Определение бизнес-процессов часто начинается с основных процессов компании, поскольку они
Для компании
Область действия бизнес-процесса должна быть выбрана таким образом, чтобы она содержала управляемое количество подпроцессов, в то же время сохраняя общее количество бизнес-процессов в разумных пределах. Обычно от пяти до восьми бизнес-процессов на бизнес-единицу покрывают диапазон производительности компании.
Каждый бизнес-процесс должен быть независимым, но процессы взаимосвязаны.
Определение бизнес-процесса включает в себя: Какой результат должен быть достигнут по завершении? Какие действия необходимы для его достижения? Какие объекты должны быть обработаны (заказы, сырье, закупки, продукция, ...)?
В зависимости от преобладающей корпоративной культуры, которая может быть более склонной к принятию изменений или защите статус-кво и эффективности коммуникации, определение бизнес-процессов может оказаться либо простым, либо сложным. Это зависит от готовности ключевых заинтересованных сторон в организации, таких как руководители отделов, оказать поддержку начинанию. В этом контексте эффективная коммуникация играет ключевую роль.
Разъясняя этот момент, Йорг Беккер и Фолькер Мейсе разъясняют, что стратегия коммуникации в рамках инициативы по организационному проектированию должна быть направлена на получение поддержки со стороны членов организации для предполагаемых структурных изменений. Стоит отметить, что моделирование бизнес-процессов обычно предшествует оптимизации бизнес-процессов, что влечет за собой реконфигурацию организации процессов — факт, хорошо понятный вовлеченным сторонам. Поэтому стратегия коммуникации должна быть сосредоточена на убеждении членов организации одобрить запланированные структурные изменения." [7] (Глава 4.15 Влияние на проектирование нормативной базы) ← автоматический перевод с немецкого Однако в случае значительного сопротивления внешние знания также могут быть использованы для определения бизнес-процессов.
Йорг Беккер и Фолькер Мейсе упоминают два подхода ( общая идентификация процессов и идентификация индивидуальных процессов ) и утверждают следующее об общей идентификации процессов: «В определении общего процесса предполагается, что существуют базовые, общеприменимые процессы, которые одинаковы во всех компаниях». Далее говорится: «Для общей идентификации процессов могут также использоваться подробные справочные модели. Они описывают отраслевые или системно-специфические процессы организации, которые еще необходимо адаптировать к индивидуальному случаю, но которые уже скоординированы в своей структуре». [7] (Глава 4.11 Общая идентификация процессов) ← автоматический перевод с немецкого
Йорг Беккер и Фолькер Мейсе утверждают следующее об идентификации индивидуальных процессов: «При идентификации индивидуальных или единичных процессов предполагается, что процессы в каждой компании различаются в зависимости от потребностей клиентов и конкурентной ситуации и могут быть идентифицированы индуктивно на основе индивидуальной проблемной ситуации». [7] (Глава 4.12 Идентификация индивидуальных процессов) ← автоматический перевод с немецкого
Результатом определения бизнес-процессов обычно является грубая структура бизнес-процессов в виде диаграммы цепочки создания стоимости.
Грубая структура бизнес-процессов, созданных до сих пор, теперь будет декомпозирована - путем разбиения ее на подпроцессы, которые имеют свои собственные атрибуты, но также способствуют достижению цели бизнес-процесса. Эта декомпозиция должна быть в значительной степени подвержена влиянию приложения и стратегии для долгосрочного успеха моделирования бизнес-процессов и должна быть продолжена до тех пор, пока адаптация подпроцессов, определенных таким образом, способствует реализации цели и стратегии .
Подпроцесс, созданный таким образом, использует модель для описания способа выполнения процедур для достижения предполагаемых операционных целей компании. Модель является абстракцией реальности (или целевого состояния), а ее конкретная форма зависит от предполагаемого использования (применения).
Дальнейшая декомпозиция подпроцессов может затем иметь место в ходе моделирования бизнес-процесса, если это необходимо. Если бизнес-процесс может быть представлен как последовательность фаз, разделенных вехами , декомпозиция на фазы является обычной. Где это возможно, перенос вех на следующий уровень декомпозиции способствует общему пониманию.
Результатом дальнейшей структуризации бизнес-процессов обычно является иерархия подпроцессов, представленная в диаграммах цепочки создания стоимости. Обычно не все бизнес-процессы имеют одинаковую глубину декомпозиции. В частности, бизнес-процессы, которые не имеют отношения к безопасности, не требуют больших затрат или не способствуют достижению операционной цели, декомпозируются на гораздо меньшую глубину. Аналогично, в качестве предварительного этапа декомпозиции процесса, запланированного на (гораздо) более позднее время, общее понимание может быть сначала разработано с использованием более простых / менее сложных средств, чем диаграммы цепочки создания стоимости - например, с помощью текстового описания или с помощью диаграммы черепахи [22] (Глава 3.1 Определение деталей процесса) ← автоматический перевод с немецкого (не путать с графикой черепахи !).
Полные, самостоятельные процессы обобщаются и передаются ответственному лицу или команде. Владелец процесса отвечает за успех, создает рамочные условия и координирует свой подход с подходами других владельцев процессов. Кроме того, он/она отвечает за обмен информацией между бизнес-процессами. Такая координация необходима для достижения общей целевой ориентации.
Если бизнес-процессы документируются с использованием определенной ИТ-системы и представления, например, графического, то это обычно называется моделированием. Результатом документирования является модель бизнес-процесса .
Вопрос о том, следует ли создавать модель бизнес-процесса посредством моделирования как есть или подвергать моделированию, во многом зависит от определенного применения и стратегии долгосрочного успеха моделирования бизнес-процессов . Предыдущая процедура с анализом бизнес-деятельности, определением бизнес-процессов и дальнейшей структуризацией бизнес-процессов целесообразна в любом случае.
Ансгар Швегманн и Михаэль Ласке объясняют: «Определение текущего статуса является основой для выявления слабых сторон и локализации потенциала для улучшения. Например, можно определить слабые места, такие как организационные разрывы или недостаточное проникновение ИТ». [23] (Глава 5.1. Намерение моделирования « как есть» ) ← автоматический перевод с немецкого
Против моделирования as is говорят следующие недостатки :
Эти аргументы становятся особенно весомыми, если реинжиниринг бизнес-процессов (BPR) все равно планируется.
Ансгар Швегманн и Михаэль Ласке также перечисляют ряд преимуществ моделирования «как есть »: [23] (Глава 5.1 Цель моделирования «как есть») ← автоматический перевод с немецкого
Также можно найти и другие преимущества, такие как:
Марио Шпек и Норберт Шнетгёке определяют цель моделирования следующим образом: «Целевые процессы основаны на стратегических целях компании. Это означает, что все подпроцессы и отдельные виды деятельности компании должны быть проанализированы с точки зрения их целевого вклада. Подпроцессы или виды деятельности, которые не могут быть идентифицированы как добавляющие ценность и не служат хотя бы одной неденежной корпоративной цели, должны быть поэтому исключены из бизнес-процессов». [8] (Глава 6.2.3 Сбор и документирование моделей )
Они также перечисляют пять основных принципов, которые доказали свою ценность при создании моделей :
Модель бизнес-процесса, созданная с помощью моделирования «как есть» или «как должно быть», состоит из:
Говорят, что Август В. Шеер сказал в своих лекциях: Процесс есть процесс есть процесс. Это призвано выразить рекурсивность термина, потому что почти каждый процесс может быть разбит на более мелкие процессы (подпроцессы). В этом отношении такие термины, как бизнес-процесс , основной процесс , подпроцесс или элементарный процесс, являются лишь отчаянной попыткой назвать уровень декомпозиции процесса. Поскольку не существует универсального соглашения о детализации бизнес-процесса , основного процесса , подпроцесса или элементарного процесса , эти термины не являются универсально определенными, а могут быть поняты только в контексте соответствующей модели бизнес-процесса.
Кроме того, некоторые немецкоязычные школы бизнес-информатики не используют термины « процесс » (в смысле представления последовательности действий ) и «функция» (в смысле разграниченной корпоративной функции /области действия (деятельности), которая четко закреплена за владельцем корпоративной функции ).
Например, в ARIS Августа В. Шеера можно использовать функции из представления функций как процессы в представлении управления и наоборот. Хотя это имеет то преимущество, что уже определенные процессы или функции могут быть повторно использованы по всем направлениям, это также означает, что надлежащее назначение представления функций размывается, и пользователь ARIS больше не может отделить процессы и функции друг от друга.
На первом изображении в виде диаграммы цепочки создания стоимости показано, как бизнес-процесс «Редактирование воронки продаж» был разбит на подпроцессы (в смысле представления последовательности действий (мероприятий)) на основе его фаз.
На втором изображении показан фрагмент типичных функций (в смысле разграниченных корпоративных функций /областей действия (деятельности), которые закреплены за владельцем корпоративной функции ), которые структурированы на основе иерархии областей компетенции и ответственности. Корпоративные функции , которые поддерживают бизнес-процесс Edit sales pipeline, отмечены в дереве функций.
Бизнес-процесс может быть разложен на подпроцессы до тех пор, пока дальнейшая декомпозиция не станет осмысленной/возможной (наименьший осмысленный подпроцесс = элементарный процесс ). Обычно все уровни декомпозиции бизнес-процесса документируются в одной и той же методологии: Символы процесса. Символы процесса, используемые при моделировании одного уровня декомпозиции, затем обычно относятся к подпроцессам следующего уровня, пока не будет достигнут уровень элементарных процессов . Диаграммы цепочки создания стоимости часто используются для представления бизнес-процессов , основных процессов , подпроцессов и элементарных процессов .
Рабочий процесс — это представление последовательности задач, заявленных как работа человека, простого или сложного механизма, группы людей, [24] организации персонала или машин (включая ИТ-системы). Поэтому рабочий процесс всегда находится на уровне элементарного процесса. Рабочий процесс можно рассматривать как любую абстракцию реальной работы, разделенную на разделение работы, разделение работы или другие типы упорядочения. Для целей контроля рабочий процесс может быть представлением реальной работы в выбранном аспекте.
Термин «функции» часто используется как синоним ограниченной корпоративной области функций/действий (activita), которая назначается владельцу корпоративной функции , и атомарной активности (задачи) на уровне элементарных процессов . Чтобы избежать двойного значения термина « функция» , термин « задача » может использоваться для атомарных активностей на уровне элементарных процессов в соответствии с именованием в BPMN. Современные инструменты также предлагают автоматическое преобразование задачи в процесс , так что в любое время можно создать еще один уровень декомпозиции процесса, на котором задача затем должна быть повышена до элементарного процесса .
Графические элементы, используемые на уровне элементарных процессов, затем описывают (временно-логическую) последовательность с помощью функций ( задач ). Последовательность функций ( задач ) в элементарных процессах определяется их логической связью друг с другом ( логическими операторами или шлюзами ), при условии, что она еще не указана отношениями ввода/вывода или вехами. Обычно используются дополнительные графические элементы для иллюстрации интерфейсов, состояний (событий), условий (правил), вех и т. д., чтобы лучше прояснить процесс. В зависимости от используемого инструмента моделирования используются очень разные графические представления ( модели ).
Кроме того, функции ( задачи ) могут быть дополнены графическими элементами для описания входов, выходов, систем, ролей и т. д. с целью повышения точности описания и/или увеличения количества деталей. Однако эти дополнения быстро делают модель запутанной . Для разрешения противоречия между точностью описания и ясностью существует два основных решения: передача дополнительных графических элементов для описания входов, выходов, систем, ролей и т. д. на аутсорсинг диаграммы распределения функций (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]
Интеграция внешних документов и ИТ-систем может значительно повысить добавленную стоимость модели бизнес-процесса.
Например, прямой доступ к объектам в базе знаний или документам в структуре правил может значительно увеличить преимущества модели бизнес-процессов в повседневной жизни и, таким образом, принятие моделирования бизнес-процессов. Все задействованные ИТ-системы могут использовать свои особые преимущества и взаимно обогащать друг друга (например, связываться друг с другом или стандартизировать структуру файлов):
Если все соответствующие объекты базы знаний и/или документы структуры правил подключены к процессам, конечные пользователи имеют контекстно-зависимый доступ к этой информации и им не нужно знать соответствующую структуру хранения подключенных систем.
Прямое подключение внешних систем также может использоваться для интеграции текущих результатов измерений или состояний систем в процессы (и, например, для отображения текущего рабочего состояния процессов), для отображения виджетов и отображения выходных данных из внешних систем или для перехода к внешним системам и инициирования там транзакции с помощью предварительно настроенного диалога.
Дополнительные подключения к внешним системам могут использоваться, например, для электронного обмена данными (EDI).
Речь идет о проверке наличия избыточности. Если да, то соответствующие подпроцессы объединяются. Или подпроцессы, которые используются более одного раза, передаются на аутсорсинг для поддержки процессов. Для успешной консолидации модели может потребоваться пересмотреть исходную декомпозицию подпроцессов.
Ансгар Швегманн и Михаэль Ласке объясняют: «Объединение моделей различных комплексов моделирования необходимо для получения интегрированной ... модели». [23] (Глава 5.2.4 Объединение моделей) ← автоматический перевод с немецкого Они также перечисляют ряд аспектов, для которых объединение моделей важно:
Цепочка подпроцессов друг с другом и цепочка функций ( задач ) в подпроцессах моделируется с использованием шаблонов потока управления.
Существенные детали цепочки (что предшествующий элемент поставляет последующему элементу?) указываются в интерфейсах процесса, если это предусмотрено.
Интерфейсы процессов определяются для того, чтобы
Как правило, это то, что и его структура определяются требованиями последующего процесса.
Интерфейсы процессов представляют собой выход из текущего бизнес-процесса/подпроцесса и вход в последующий бизнес-процесс/подпроцесс.
Интерфейсы процессов являются, таким образом, элементами описания для связывания процессов по разделам. Интерфейс процесса может
Интерфейсы процессов согласовываются между участниками вышестоящих/подчиненных или соседних моделей бизнес-процессов. Они определяются и связываются один раз и используются так часто, как это требуется в моделях процессов .
Интерфейсы могут быть определены следующим образом:
В реальном выражении передаваемые входы/выходы часто представляют собой данные или информацию, но также возможны любые другие бизнес-объекты (материалы, продукты в их конечном или полуфабрикатном состоянии, документы, такие как счет на поставку). Они предоставляются через подходящие транспортные среды (например, хранилище данных в случае данных).
См. статью Управление бизнес-процессами.
Для внедрения улучшенных бизнес-процессов обычно требуются программы управления изменениями . С развитием дизайна программного обеспечения видение моделей BPM, которые полностью исполняемы (позволяя проводить симуляции и круговую инженерию), становится все ближе к реальности.
В управлении бизнес-процессами потоки процессов регулярно пересматриваются и оптимизируются (адаптируются) при необходимости. Независимо от того, вызвана ли эта адаптация потоков процессов постоянным совершенствованием процесса или реорганизацией процесса (реинжинирингом бизнес-процессов), она влечет за собой обновление отдельных подпроцессов или всего бизнес-процесса.
На практике распространены комбинации неформальных , полуформальных и формальных моделей: неформальные текстовые описания для объяснения, полуформальное графическое представление для визуализации и формальное языковое представление для поддержки моделирования и перевода в исполняемый код.
Существуют различные стандарты обозначений; наиболее распространенными являются:
Более того:
Кроме того, могут быть использованы типы представления из архитектуры программного обеспечения :
Модель и нотация бизнес-процессов (BPMN) — это графическое представление для описания бизнес-процессов в модели бизнес-процессов.
Первоначально разработанный Business Process Management Initiative (BPMI), BPMN поддерживается Object Management Group (OMG) с момента слияния двух организаций в 2005 году. Версия 2.0 BPMN была выпущена в январе 2011 года, [30] в этот момент название было изменено на Business Process Model and Notation, чтобы отразить введение семантики выполнения, которая была введена вместе с существующими элементами нотации и диаграммирования. Хотя это спецификация OMG, BPMN также ратифицирован как ISO 19510. Последняя версия — BPMN 2.0.2, опубликованная в январе 2014 года. [31]
Цепочка процессов, управляемых событиями (EPC), — это тип блок-схемы для моделирования бизнес-процессов. EPC можно использовать для настройки выполнения планирования ресурсов предприятия и для улучшения бизнес-процессов . Его можно использовать для управления автономным экземпляром рабочего процесса при разделении работы.
Метод цепочки событий, управляемых событиями, был разработан в рамках архитектуры интегрированных информационных систем (ARIS) Августом-Вильгельмом Шеером в Institut für Wirtschaftsinformatik, Universität des Saarlandes (Институт систем бизнес-информации при Университете Саара) в начале 1990-е годы. [32]Сеть Петри , также известная как сеть мест/переходов (PT net), является одним из нескольких языков математического моделирования для описания распределенных систем . Это класс дискретно-событийных динамических систем . Сеть Петри представляет собой направленный двудольный граф , который имеет два типа элементов: места и переходы. Элементы мест изображаются белыми кругами, а элементы переходов изображаются прямоугольниками. Место может содержать любое количество токенов, изображаемых черными кругами. Переход разрешен, если все места, подключенные к нему в качестве входов, содержат хотя бы один токен. Некоторые источники [33] утверждают, что сети Петри были изобретены в августе 1939 года Карлом Адамом Петри — в возрасте 13 лет — с целью описания химических процессов.
Подобно отраслевым стандартам, таким как диаграммы активности UML , модель и нотация бизнес-процессов и цепочки процессов, управляемые событиями , сети Петри предлагают графическую нотацию для пошаговых процессов, которые включают выбор, итерацию и параллельное выполнение . В отличие от этих стандартов, сети Петри имеют точное математическое определение семантики своего выполнения с хорошо развитой математической теорией для анализа процесса [ требуется ссылка ] .
Блок -схема — это тип диаграммы , которая представляет собой рабочий процесс или последовательность действий . Блок-схему также можно определить как схематическое представление алгоритма , пошагового подхода к решению задачи.
Блок-схема показывает шаги в виде блоков различных видов, а их порядок — путем соединения блоков стрелками. Это схематическое представление иллюстрирует модель решения данной проблемы. Блок-схемы используются при анализе, проектировании, документировании или управлении процессом или программой в различных областях. [34]
Язык моделирования жизненного цикла (LML) — это язык моделирования с открытым стандартом, разработанный для системной инженерии . Он поддерживает полный жизненный цикл : этапы концептуального, использования, поддержки и вывода из эксплуатации. Наряду с интеграцией всех дисциплин жизненного цикла, включая управление программами , системное и проектное проектирование , верификацию и валидацию , развертывание и обслуживание в одну структуру. [38] LML изначально был разработан руководящим комитетом LML. Спецификация была опубликована 17 октября 2013 года.
Это язык моделирования, подобный UML и SysML , который поддерживает дополнительные применения управления проектами, такие как анализ рисков и планирование. LML использует общий язык для определения своих элементов моделирования, таких как сущность, атрибут, расписание, стоимость и связь. [39]Субъектно-ориентированное управление бизнес-процессами (S-BPM) — это основанный на коммуникации взгляд на действующих лиц (субъектов), которые составляют оркестровку или хореографию бизнес-процесса. [40] Парадигма моделирования использует пять символов для моделирования любого процесса и допускает прямое преобразование в исполняемую форму.
Каждый бизнес-процесс состоит из двух или более субъектов , которые обмениваются сообщениями . Каждый субъект имеет внутреннее поведение (капсуляцию), которое определяется как поток управления между различными состояниями, которые получают и отправляют сообщения и делают что-то . Для практического использования и для синтаксического сахара доступно больше элементов, но не обязательно.
В 2011 и 2012 годах S-BPM был включен в отчет Gartner Hype Cycle .Cognition enhancement Natural language Information Analysis Method (CogNIAM) — это концептуальный метод моделирования на основе фактов , который направлен на интеграцию различных измерений знаний: данных, правил, процессов и семантики. Для представления этих измерений используются мировые стандарты SBVR , BPMN и DMN от Object Management Group (OMG). CogNIAM, преемник NIAM , основан на работе ученого-знатока Сйира Нейссена . [ требуется ссылка ]
CogNIAM структурирует знания, собранные от людей, документации и программного обеспечения, классифицируя их. Для этой цели CogNIAM использует так называемый «Треугольник знаний». [41] Результат CogNIAM не зависит от человека, который его применяет. Полученная модель позволяет выразить знания в виде диаграммы , а также на контролируемом естественном языке . [42]
Унифицированный язык моделирования (UML) — это визуальный язык моделирования общего назначения , предназначенный для предоставления стандартного способа визуализации проекта системы. [45]
UML предоставляет стандартную нотацию для многих типов диаграмм, которые можно условно разделить на три основные группы: диаграммы поведения, диаграммы взаимодействия и диаграммы структуры.
Создание UML изначально было мотивировано желанием стандартизировать разрозненные системы обозначений и подходы к проектированию программного обеспечения. Он был разработан в Rational Software в 1994–1995 годах, а его дальнейшее развитие велось ими до 1996 года. [46]
В 1997 году UML был принят в качестве стандарта Object Management Group (OMG) и с тех пор управляется этой организацией. В 2005 году UML был также опубликован Международной организацией по стандартизации (ISO) и Международной электротехнической комиссией (IEC) как стандарт ISO/IEC 19501. [47] С тех пор стандарт периодически пересматривался, чтобы соответствовать последней редакции UML. [48]
В программной инженерии большинство специалистов не используют UML, а вместо этого создают неформальные диаграммы, нарисованные вручную; однако эти диаграммы часто включают элементы из UML. [49] : 536
IDEF , изначально аббревиатура ICAM Definition и переименованная в 1999 году в Integration Definition, — это семейство языков моделирования в области системной и программной инженерии. Они охватывают широкий спектр применения от функционального моделирования до данных, моделирования, объектно-ориентированного анализа и проектирования , а также приобретения знаний. Эти языки определения были разработаны при финансировании со стороны ВВС США и, хотя по-прежнему чаще всего используются ими и другими военными и министерством обороны США (DoD) агентствами, находятся в открытом доступе.
Наиболее широко признанными и используемыми компонентами семейства IDEF являются IDEF0, язык функционального моделирования, созданный на основе SADT, и IDEF1X, который решает проблемы информационных моделей и проектирования баз данных.
Моделирование процессов по Харбариану (HPM) — это метод получения информации о внутренних процессах организации и последующего документирования этой информации в наглядной и простой форме.
Метод HPM включает два уровня:
Инструменты моделирования бизнес-процессов предоставляют бизнес-пользователям возможность моделировать свои бизнес-процессы, внедрять и выполнять эти модели, а также совершенствовать модели на основе данных, полученных в процессе выполнения. В результате инструменты моделирования бизнес-процессов могут обеспечить прозрачность бизнес-процессов, а также централизацию корпоративных моделей бизнес-процессов и показателей выполнения. [51] Инструменты моделирования также могут обеспечивать совместное моделирование сложных процессов пользователями, работающими в командах, где пользователи могут совместно использовать и моделировать модели. [52] Инструменты моделирования бизнес-процессов не следует путать с системами автоматизации бизнес-процессов — обе практики используют моделирование процесса в качестве одного и того же начального шага, и разница в том, что автоматизация процессов дает вам «исполняемую диаграмму», и это кардинально отличается от традиционных графических инструментов моделирования бизнес-процессов. [ требуется цитата ]
Программное обеспечение пакета BPM предоставляет программные интерфейсы (веб-сервисы, интерфейсы прикладных программ (API)), которые позволяют создавать корпоративные приложения для использования механизма BPM. [51] Этот компонент часто называют механизмом пакета BPM.
Языки программирования, которые внедряются для BPM, включают: [53]
Некоторые языки, специфичные для поставщика:
Другие технологии, связанные с моделированием бизнес-процессов, включают архитектуру на основе моделей и сервисно-ориентированную архитектуру .
Функциональность моделирования таких инструментов позволяет проводить предварительное моделирование "что-если" (которое имеет особые требования для этого приложения) и моделирование. Оптимизация после выполнения доступна на основе анализа фактических показателей выполнения. [51]
Бизнес -эталонная модель — это эталонная модель, концентрирующаяся на функциональных и организационных аспектах предприятия , сервисной организации или государственного учреждения . В общем, эталонная модель — это модель чего-либо, которая воплощает основную цель или идею чего-либо и затем может рассматриваться как эталон для различных целей. Бизнес-эталонная модель — это средство описания бизнес-операций организации, независимо от организационной структуры, которая их выполняет. Другие типы бизнес-эталонных моделей также могут отображать взаимосвязь между бизнес-процессами, бизнес-функциями и бизнес-эталонной моделью бизнес-области. Эти эталонные модели могут быть построены по слоям и предлагают основу для анализа компонентов услуг, технологий, данных и производительности.
Наиболее известная бизнес-модель — это бизнес-модель федерального правительства США. Эта модель представляет собой функциональную структуру для описания бизнес-операций федерального правительства независимо от агентств, которые их выполняют. Бизнес-модель предоставляет организованную иерархическую конструкцию для описания повседневных бизнес-операций федерального правительства. Хотя существует множество моделей для описания организаций — организационные схемы , карты местоположений и т. д. — эта модель представляет бизнес с использованием функционально-ориентированного подхода. [55]
Бизнес-модель, которую можно считать разработкой модели бизнес-процессов, обычно показывает бизнес-данные и бизнес-организации, а также бизнес-процессы. Демонстрируя бизнес-процессы и их информационные потоки, бизнес-модель позволяет заинтересованным сторонам бизнеса определять, понимать и проверять свое бизнес-предприятие. Часть модели данных бизнес-модели показывает, как хранится бизнес-информация, что полезно для разработки программного кода . См. рисунок справа для примера взаимодействия между моделями бизнес-процессов и моделями данных. [56]
Обычно бизнес-модель создается после проведения интервью, которое является частью процесса бизнес-анализа . Интервью состоит из того, что ведущий задает ряд вопросов для извлечения информации о рассматриваемом бизнес-процессе. Интервьюера называют посредником, чтобы подчеркнуть, что именно участники, а не посредник, предоставляют информацию о бизнес-процессе. Хотя посредник должен иметь некоторые знания о рассматриваемом бизнес-процессе, но это не так важно, как владение прагматичным и строгим методом интервьюирования бизнес-экспертов. Метод важен, потому что для большинства предприятий необходима команда посредников для сбора информации по всему предприятию, а выводы всех интервьюеров должны быть собраны и интегрированы после завершения. [56]
Бизнес-модели разрабатываются как определяющие либо текущее состояние процесса, в этом случае конечный продукт называется моделью снимка «как есть», либо как концепция того, каким должен стать процесс, в результате чего получается модель «как есть». Сравнивая и противопоставляя модели «как есть» и «как будет», бизнес-аналитики могут определить, являются ли существующие бизнес-процессы и информационные системы надежными и требуют лишь незначительных изменений, или требуется реинжиниринг для исправления проблем или повышения эффективности. Следовательно, моделирование бизнес-процессов и последующий анализ могут использоваться для фундаментального изменения способа ведения предприятием своих операций. [56]
Реинжиниринг бизнес-процессов (BPR) направлен на повышение эффективности и результативности процессов, существующих внутри и между организациями. Он изучает бизнес-процессы с точки зрения «чистого листа», чтобы определить, как лучше всего их построить.
Реинжиниринг бизнес-процессов (BPR) начинался как метод частного сектора, призванный помочь организациям фундаментально переосмыслить то, как они выполняют свою работу. Ключевым стимулом для реинжиниринга стала разработка и внедрение сложных информационных систем и сетей. Ведущие организации используют эту технологию для поддержки инновационных бизнес-процессов, а не для совершенствования текущих способов выполнения работы. [57]
Программы управления изменениями обычно используются для внедрения любых улучшенных бизнес-процессов. С развитием дизайна программного обеспечения видение моделей BPM, которые станут полностью исполняемыми (и смогут выполнять симуляции и круговую инженерию), становится все ближе к реальности.
В управлении бизнес-процессами потоки процессов регулярно пересматриваются и, при необходимости, оптимизируются (адаптируются). Независимо от того, вызвана ли эта адаптация потоков процессов постоянным процессом улучшения или реинжинирингом бизнес-процессов, она влечет за собой обновление отдельных подпроцессов или всего бизнес-процесса.
{{cite web}}: CS1 maint: bot: original URL status unknown (link)доступ получен 19 февраля 2024 г.
Медиа, связанные с моделированием бизнес-процессов на Wikimedia Commons{{|bot=InternetArchiveBot |fix-attempted=yes}}